Добрый день! ПГ 11.1 drop table core_operation_2021_01_03; ERROR: cache lookup failed

for publication 5467073

куда рыть ?

Для начала — в сторону обновления до 11.21, очевидно.

не очевидно. в 11.4 ломается прунинг секций

Выглядит как какие-то сказки, извините. Или покажите то, о чём речь. Альтернативный вариант — страдайте дальше, что ж (или вручную "втащите" fixes из 20 minor releases в Ваш, т.е. соберите из исходников и т.п.). Edit: И вообще, по поводу этого "ломается" — Вы вечно собираетесь на v11 оставаться или как? Потому что другого варианта не столкнуться с "проблемой" я как-то не вижу, а Вы?

в начале года обсуждали тут же у меня 6 вроде как одинаковых ПГ11 но только на одном запросы педалили и план строился без пруна и тут народ подсказал глянуть точную версию оказалось что на 5 - 11.1, а на одном 11.14 сначала апнул вверх на 11.19 на тот момент, не помогло. потом откатил на 11.2. (11.1 почему-то в репе не было) прун заработал. ради интереса стал апать по минорам - нашел что 11.4 ломает прун. оказалось что действительно какие-то рукожопы в нем поковырялись: Release Notes PostgreSQL 11.4 Release date: 2019-06-20 Fix assorted errors in run-time partition pruning logic (Tom Lane, Amit Langote, David Rowley) конкретно CentOS Linux 7 (Core) PostgreSQL 11.4 и выше до 11.19 прун сломан. про обновление выше 11, это не ко мне, заказчик никак не созреет. работаем с тем что есть.

И вам тогда жэ вроде говорили, что у вас запрос сломан. Перепишыте на корректное приведение типов — будет работать. Так что рукожоп тут есть, но совсем не в core team постгреса...

про запросы не помню. и в истории телеги тот случай не нашел совсем ((( но если запрос работал и перестал, то почему сломан запрос ? SELECT * FROM core_document WHERE issued_at >= '2023-08-08 00:00:00' AND issued_at <= '2023-08-08 23:59:59'; что вот тут сломано ? зы секции по issued_at timestamptz

ни в чем) лень всем было))))

Вы понимаете, что Ваш вопрос аналогичен примерно следующему: "А если запрос SELECT 1+1; работал (но возвращал 3 (три)), а потом (после каких-то исправлений в СУБД) перестал (стал возвращать 2, какой ужас!), то почему сломан запрос?!" Я, кстати, не нашёл то обсуждение, о котором речь... так что я пока поверю @tzirechnoy относительного того, в чём там на самом деле проблема. ;)

не аналогичен. был заявленный cast если авттор прав что слолммаля именно этот

Целая секунда у вас такими запросами теряется. Это я чисто подушнить про «больше/меньше».

Про последнее — как "созреют", они неизбежно с этим столкнутся, так что им стоило бы решить нормально... и да, это в самом деле не Ваша проблема. :)

Скорее всего — напрягает, что парзинг timestamptz является volatile (зависит от таймзоны сэссии). Проверять в общем надо.

Я ничего конкретного пока не видел, а в плане того, у кого, эээ... "руки кривые", я смело ставлю не на ведущих разработчиков PostgreSQL.

я могу показать. есть серваки тестовые. что конкретно предоставить ?

Запрос, \d+ и expain (analyze, buffers). Версию мы и так видим, хе-хе.

Да как обычно: https://t.me/pgsql/476688 (с того и другого сервера).

про разработчиков постгреса. беру свои слова обратно и приношу свои искренние извинения. тут редкий кейс в который сложно попасть. секционные таблицы select/insert only в секциях примерно по 1-10М записей как оказалось автовакум не проходил никогда. я про это тут писал, ответили что это бага ПГ11. и вот в этом случае, прун после 11.4 перестает работать. после первого вакума прун начинает работать.

Что такие «прун» в вашем случае ))))

именно это 5.10.4. Partition Pruning Partition pruning is a query optimization technique that improves performance for declaratively partitioned tables. когда запрос с условием по ключу секционирования планировщик сам отсекает лишние секции а в остальных ищет

ну вы правы то что извиятьтся то