Size: a a a

pgsql – PostgreSQL

2020 May 19

ДЛ

Дмитрий Лукьянов... in pgsql – PostgreSQL
Yaroslav Schekin
Т.е. log_min_duration_statement вообще закомментирован, а log_statement — только DDL?
Тогда непонятно, почему у Вас вообще обычные запросы логируются. ;)
Может, попробовать посмотреть эти значения в тестовой сессии (максимально похожей на настоящую — под тем же пользователем в той же базе и т.п.) в psql (вдруг эти настройки приходят откуда-то ещё)?
Поменял log_statement на all временно. Начали валиться с биндами запросы.
Спасибо.
источник

AL

Andrey Lepekha in pgsql – PostgreSQL
Всем привет. Есть вопрос по параллельном обновлении одной записи. У меня есть 5 консьюмеров которые обновляют (инкрементят каунтер у одной и той же записи). Но например если приходит сразу же 5 сообщений в очереди, то все 5 консьюмеров пытаются параллельно инкрементить одну и ту же запись. Запись достаю через SELECT FOR UPDATE, и вроде как она должна блокироваться пока не выполнится инкремент в одном из консьюмеров. Кто как решал данный вопрос?
источник

VG

Viktor Grigorev in pgsql – PostgreSQL
2flower _
вы план смотрели?
https://explain.depesz.com/s/j3rf - первый запрос
https://explain.depesz.com/s/8Cox - второй запрос
источник

VG

Viktor Grigorev in pgsql – PostgreSQL
насколько могу судить разница в rows=1 width=0 и  rows=1 width=4
источник

РЖ

Роман Жарков... in pgsql – PostgreSQL
Andrey Lepekha
Всем привет. Есть вопрос по параллельном обновлении одной записи. У меня есть 5 консьюмеров которые обновляют (инкрементят каунтер у одной и той же записи). Но например если приходит сразу же 5 сообщений в очереди, то все 5 консьюмеров пытаются параллельно инкрементить одну и ту же запись. Запись достаю через SELECT FOR UPDATE, и вроде как она должна блокироваться пока не выполнится инкремент в одном из консьюмеров. Кто как решал данный вопрос?
В таком простом случае оно само все блокировки сделает.
Если там field = field + 1;
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Andrey Lepekha
Всем привет. Есть вопрос по параллельном обновлении одной записи. У меня есть 5 консьюмеров которые обновляют (инкрементят каунтер у одной и той же записи). Но например если приходит сразу же 5 сообщений в очереди, то все 5 консьюмеров пытаются параллельно инкрементить одну и ту же запись. Запись достаю через SELECT FOR UPDATE, и вроде как она должна блокироваться пока не выполнится инкремент в одном из консьюмеров. Кто как решал данный вопрос?
Вы там очередь хотите реализовать (если я правильно понял)?
Если да — посмотрите на "SELECT FOR UPDATE SKIP LOCKED", он как раз для этого (насколько я помню, легко гуглятся готовые примеры).
источник

AL

Andrey Lepekha in pgsql – PostgreSQL
Роман Жарков
В таком простом случае оно само все блокировки сделает.
Если там field = field + 1;
Апдейт по дефолту блокирует только записи, где есть уникальный индекс
источник

AL

Andrey Lepekha in pgsql – PostgreSQL
По этому я юзаю select for update
источник

AL

Andrey Lepekha in pgsql – PostgreSQL
Yaroslav Schekin
Вы там очередь хотите реализовать (если я правильно понял)?
Если да — посмотрите на "SELECT FOR UPDATE SKIP LOCKED", он как раз для этого (насколько я помню, легко гуглятся готовые примеры).
Спасибо, гляну
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Viktor Grigorev
насколько могу судить разница в rows=1 width=0 и  rows=1 width=4
Ну да. Просто чуть меньше данных "проходит" по узлам плана, да и всё (а вообще, было бы немного странно, если есть достоверное отличие — в том смысле, что иногда не бывает наоборот при повторных выполнениях;  разница всё равно небольшая, на первый взгляд).
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Andrey Lepekha
Апдейт по дефолту блокирует только записи, где есть уникальный индекс
UPDATE всегда блокирует обновляемые записи, вообще-то. Или Вы о чём-то другом?
источник

VG

Viktor Grigorev in pgsql – PostgreSQL
бывает наоборот, но гораздо чаще exists побыстрее
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Viktor Grigorev
бывает наоборот, но гораздо чаще exists побыстрее
Понятно. Всё-таки, причина для этого есть, хотя её вклад и мизерный (поэтому и бывает наоборот).
источник

AL

Andrey Lepekha in pgsql – PostgreSQL
Yaroslav Schekin
UPDATE всегда блокирует обновляемые записи, вообще-то. Или Вы о чём-то другом?
Не всегда
источник

AL

Andrey Lepekha in pgsql – PostgreSQL
источник

РЖ

Роман Жарков... in pgsql – PostgreSQL
Andrey Lepekha
Не всегда
Всегда. Оно так устроено.
источник

AL

Andrey Lepekha in pgsql – PostgreSQL
Возможно, тогда я не правильно понял доку
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Andrey Lepekha
Не всегда
Всегда. Вы неправильно поняли / не дочитали документацию.
См. далее:

FOR NO KEY UPDATE
   Behaves similarly to FOR UPDATE, except that the lock acquired is weaker: this lock will not block SELECT FOR KEY SHARE commands that attempt to acquire a lock on the same rows. This lock mode is also acquired by any UPDATE that does not acquire a FOR UPDATE lock.

Т.е. какая-то блокировка всегда накладывается при UPDATE.
источник

AL

Andrey Lepekha in pgsql – PostgreSQL
Yaroslav Schekin
Вы там очередь хотите реализовать (если я правильно понял)?
Если да — посмотрите на "SELECT FOR UPDATE SKIP LOCKED", он как раз для этого (насколько я помню, легко гуглятся готовые примеры).
Skip locked кстати не подходит, он наоборот пропускает заблокированные строки(что логично из названия). Мне нужно сделать очередь транзакций, что бы одна ждала завершение другой. По сути сейчас так и есть, но оооочень странно работает. Бывает что 5 записей нормально обновляются, и потом пару записей вообще не обновляются
источник

AL

Andrey Lepekha in pgsql – PostgreSQL
Yaroslav Schekin
Всегда. Вы неправильно поняли / не дочитали документацию.
См. далее:

FOR NO KEY UPDATE
   Behaves similarly to FOR UPDATE, except that the lock acquired is weaker: this lock will not block SELECT FOR KEY SHARE commands that attempt to acquire a lock on the same rows. This lock mode is also acquired by any UPDATE that does not acquire a FOR UPDATE lock.

Т.е. какая-то блокировка всегда накладывается при UPDATE.
Да, вижу, спасибо за инфу👍
источник