я такое делал в много филиальной  сети, филиалы  могут отваливаться на неоперённое время. Благо бизнес процессы позволяли  кэшировать данные для непрерывной работы  без центра

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

autovacuum  on
autovacuum_analyze_scale_factor  0.1
autovacuum_analyze_threshold  50
autovacuum_freeze_max_age  200000000
autovacuum_max_workers  6
autovacuum_multixact_freeze_max_age  400000000
autovacuum_naptime  30
autovacuum_vacuum_cost_delay  10
autovacuum_vacuum_cost_limit  10000
autovacuum_vacuum_scale_factor  0.1
autovacuum_vacuum_threshold  10000
log_autovacuum_min_duration 0

Кому интересно, то решили вопрос. В логах были ошибки вида -  error '[XX000] ERROR: wrong tuple length'. В БД было около 700 юзеров с пермишинами на отдельную схему в БД на view. Забрали права и дали обратно те же - вакуум заработал.

Может кто сталкивался с таким глюком? Постгрес 11 не может найти строку в таблице по текстовому полю.

В таблице есть две записи с полем token типа text с одинаковым значением token = 'string'. При запросе where token = 'string' или where token like 'string' выводит только одну запись, но если сделать where token like '%string' или вообще вместо любого символа поставить процент - находит обе. Значения равны, сравнивал и напрямую, и через md5. Добавил руками две новые записи с другими одинаковыми значениями - там все нормально.
Строка алфавитно-цифровая, без спецсимволов.

БД в докер-композе.

volumes:
     - ./postgres/dpt-bd.sql:/docker-entrypoint-initdb.d/dbt-bd.sql

В папке проекта файлик базы.

При поднятии docker-compose данные вычитываются из этого файлика.
Если перед поднятием докера в файлике руками внести изменения, то поднятая база их показывает.

Работаю с базой, вношу изменения.
Останавливаю docker-compose.
В файлике базы изменения не появляются.

Снова поднимаю контейнеры - отображаются изменения прошлого сеанса.

Куда они записались?
И почему так?

Ведь при первом поднятии базы считался именно файл из папки проекта указанный в volumes...

Удалил контейнер и пересоздал по новой - в базу подтянулись данные из фала проекта...

Получается, что все изменения записывались и лежали в поднятом контейнере...
Почему бд работала не с volums?

Это, к сожалению, может быть тонким намёком на битый индекс. :(
Посмотрите \d таблицы, и сравните планы этих запросов.

ок

спасибо. да, в первом случае там index scan

А в другом seq. scan, так? Да, скорее всего, индекс битый — проверьте "железо" и т.п. :(
Из более "утешительного" —  выясните, актуальная ли это версия PostgreSQL, не обновляли ли недавно версию glibc в самой OS, мало ли (см. https://wiki.postgresql.org/wiki/Locale_data_changes ).

да, все так. вообще такая штука не в первый раз. железо - виртуалка на хетцнере.
реиндекс помог.

Подождите, всё как? Если это не bug / glibc и т.п. — то, что Вы сделали, это не "помощь", это Вы corruption "под ковёр замели" (т.е. данные-то уже битые, возможно). Нехорошо так поступать, если это важные данные.

> в другом seq. scan
сервер тестовый, данные не особо нужны. Но выяснить причину надо.

постгрес не самой новой версии - 11.7

Ну так обновить до 11.10 / поискать подобное в release notes, например.
Но если не найдётся — "железо" / настройки OS я бы тоже посмотрел (может, оно там fsync "теряет" и т.п.), если возможно.

Через 20 минут очередной выпуск Postgres.tv (ссылка ведёт на youtube; англоязычный канал). Илья и я позвали супиринтересного гостя -- Tomas Vondra
Подробности и зум-ссылка тут: http://bit.ly/postgres-tv

Всем привет, после удаления postgresql 12.5 с федоры 33, я установил заново. При выполнении sudo /usr/pgsql-12/bin/postgresql-12-setup initdb
пишет такое
Data directory is not empty!

Кто-нибудь может помочь? Буду благодарен)

Ну пишет же явным текстом что не нравится

а какая директория?