В PostreSQL бывает. У меня он возник, когда я вешал уникальный индекс, и в этот момент в таблицу залетел дубль (по крайней мере, я это так понял). Если \d в psql для таблицы вызвать, то там так и будет рядом с индексом указано - INVALID. А dbeaver это не помечает. У меня была ситуация, когда я из-за этого баг не мог найти, пока DBA не посоветовали посмотреть через psql.

Потому что выглядело все так, что уникальный индекс как бы есть, а дубли при этом в таблице появляются. Я ж не знал, что индекс сломан.

ну например во время reindex concurrently

Если кому-то нужен pgAdmin3, не ругающийся на новых версиях, то я сюда выкладываю свои сборки:
https://vvs.ru/pg/

в Оракле куча объектов могут быть инвалидными. тут точно такой же смысл, только решается чуть иначе

Sp, function, trigger все с кодом. А вот индекс вроде нет. Что значит invalid index ???

значит, что им нельзя пользоваться. при создании индекса CONCURRENTLY, индекс добавляется в каталог с пометкой INVALID, т.к. постройка индекса требует дважды пройти по таблице. по завершении индекс становиться валидным, если команду оборвать, то инвалидный индекс останется в системе

Спс погуглю наверняка в метадате есть флаг для индекса. Даже интересно есть ли аналогии в др. БД

Ого, не представлял такого) спасибо

Про индексы недавно на фосдеме интересная заметка была, что если вы хотите чтобы во время запроса определённый индекс не использовался, то вы можете открыть транзакцию, дропнуть индекс, выполнить запрос и откатить транзакцию.

я бы проверил как будут себя чувствовать другие сессии во время такого упражнения, чтобы ненароком не приложить проект на минутку

Это интересно, спасибо! Новые функции в pgAdmin3 добавляются?

Нет, в основном доработка, чтобы старые функции не выдавали ошибок.

Добрый день. Столкнулся с проблемой установки владения на Google CloudSQL (PostgreSQL DBaaS от гугла).
Накатываю дамп в кастом формате на чистую базу и получаю тонну ошибок вида:

pg_restore: from TOC entry 2469; 0 0 SEQUENCE OWNED BY domain_id_seq msoa_adstxt
pg_restore: error: could not execute query: ERROR:  must be owner of relation domain_id_seq
Command was: ALTER SEQUENCE public.domain_id_seq OWNED BY public.domain.id;


pg_restore: from TOC entry 2472; 0 0 SEQUENCE OWNED BY inapp_domainapp_id_seq msoa_adstxt
pg_restore: error: could not execute query: ERROR:  must be owner of relation inapp_domainapp_id_seq
Command was: ALTER SEQUENCE public.inapp_domainapp_id_seq OWNED BY public.inapp_domainapp.id;

Дамп наливаю под ролью postgres которая входит в роль cloudsqlsuperuser:

% psql -c '\dg postgres' -c '\dg cloudsqlsuperuser'
                                List of roles
┌───────────┬────────────────────────┬───────────────────────────────────────┐
│ Role name     │       Attributes       │               Member of               │
├───────────┼────────────────────────┼───────────────────────────────────────┤
│ postgres         │ Create role, Create DB │ {pg_signal_backend,cloudsqlsuperuser} │
└───────────┴────────────────────────┴───────────────────────────────────────┘

                        List of roles
┌───────────────────┬────────────────────────┬──────────────┐
│     Role name     │       Attributes       │  Member of   │
├───────────────────┼────────────────────────┼──────────────┤
│ cloudsqlsuperuser │ Create role, Create DB │ {pg_monitor} │
└───────────────────┴────────────────────────┴──────────────┘

до этого я восстанавливал базы с опцией --no-owner для pg_restore

и всё было ок, но как оказалось мои джанго приложения не могу в таком случае создавать индексы в своих базах

pg_restore: from TOC entry 2469; 0 0 SEQUENCE OWNED BY domain_id_seq msoa_adstxt
pg_restore: error: could not execute query: ERROR:  must be owner of relation domain_id_seq
Command was: ALTER SEQUENCE public.domain_id_seq OWNED BY public.domain.id;


pg_restore: from TOC entry 2472; 0 0 SEQUENCE OWNED BY inapp_domainapp_id_seq msoa_adstxt
pg_restore: error: could not execute query: ERROR:  must be owner of relation inapp_domainapp_id_seq
Command was: ALTER SEQUENCE public.inapp_domainapp_id_seq OWNED BY public.inapp_domainapp.id;

% psql -c '\dg postgres' -c '\dg cloudsqlsuperuser'
                                List of roles
┌───────────┬────────────────────────┬───────────────────────────────────────┐
│ Role name     │       Attributes       │               Member of               │
├───────────┼────────────────────────┼───────────────────────────────────────┤
│ postgres         │ Create role, Create DB │ {pg_signal_backend,cloudsqlsuperuser} │
└───────────┴────────────────────────┴───────────────────────────────────────┘

                        List of roles
┌───────────────────┬────────────────────────┬──────────────┐
│     Role name     │       Attributes       │  Member of   │
├───────────────────┼────────────────────────┼──────────────┤
│ cloudsqlsuperuser │ Create role, Create DB │ {pg_monitor} │
└───────────────────┴────────────────────────┴──────────────┘

сравните владельца таблицы domain и последовательности domain_id_seq,  также обратите внимание на пользователя, от которого вы запускаете восстановление

я запускаю pg_restore из под роли postgres

Да, действительно. Я проверил сейчас - всё плохо :)
Создал таблицу с одним полем, по нему создал индекс. Выполнил запрос на равенство с одним из значений - выдал index only scan.

В соседней сессии начал транзакцию и удалил этот индекс. После чего выполнил такой же запрос - выдал Seq Scan и пока не закрывал транзакцию вернулся в первую сессию и повторил explain analyze select * from test where ticket_no = '0005432000892'; - и этот запрос повис до тех пор пока я не откатил транзакцию во второй сессии.