Вероятно, что вы увидели последний запрос в транзакции. Т.е. перед SELECT-ом могли быть и другие запросы (DML, DDL) которые повесили блокировку. Затем эта транзакция заснула (статус idle_in_transaction) и вы получили лок.

спасибо большое!!! я как раз начал копать в этом направлении.

🤝

Именно так и делается, да. Я выше писал

Собственно, если красивее - то не весь остаток на одну позицию, а по условной копейке на очередную строку

Дельта не может превышать или быть равной количеству позиций, но да, в целом, можно эту дельту раскидать по M позициям из N позиций всего относительно равномерно, а не вешать все на одну, но тогда вам и НОД придется вычислять, и сложность алгоритма тоже возрастёт. Хотя так будет и красивее, и правильнее, тут не спорю

Подскажите где можно достать дистрибутив 9.6.6 x64 под винду, может есть где склад старых версий?

docker pull postgres:9.6.6 не подойдёт? не то, чтобы под винду, конечно, но при наличии docker desktop должно завестись

Спасибо за отклик, но простой сетап бы найти..

Вряд ли что может быть проще и полезнее докера при установке разных версий БД на одну машину.

В serializable — точно блокирует, там без этого никак.

Ничего дополнительно он там не блокирует, и без этого — ещё как. ;)

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

А в RC её нет, что ли? ;) "Ничего дополнительно он там не блокирует..."

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

Так я тоже не писал, что никаких блокировок нет.
Это уже ответ в продолжение темы — от использования SERIALIZABLE блокировок больше не становится.

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

При переводе пакетов с Oracle на Postgres возник вопрос, как быть с переменными пакета? Сами пакеты мы превращаем в схемы, функции и процедуры в функции. А вот переменные пакета пока не понимаю куда деть... по идее это переменные уровня сессии. Я так понимаю, что это делается через set package.variable = 'value' и соответственно SELECT current_setting('package.variable');? Или это плохой вариант и стоит как-то иначе?

таблица или например set_config('USER.ID', p_user_id::text, false);

А что будет эффективнее использовать? Таблица я так понимаю типа TEMP?