Вопрос по SERIALIZABLE TRANSACTION На первом скрине создаётся таблица из 184

элементов.
Всё пройдёт без ошибок.

На втором скрине создаётся аналогичная таблица, но из 185 элементов.
И тут появляется ошибка сериализации на 26 строке.

Если посмотреть взятые локи, то в обоих кейсах будет такой результат:
{ relation: 'status', locktype: 'tuple', page: 0, tuple: 1 },
{ relation: 'status_id_idx', locktype: 'page', page: 1, tuple: null },
{ relation: 'status_id_idx', locktype: 'page', page: 1, tuple: null }

Как объяснить то, что на втором скрине происходит ошибка сериализации при увеличении кол-ва элементов в таблице на 1?

А давайте без "скринов" (текста!), а? Здесь их всё равно мало кто смотрит.

А что удобно будет смотреть? Текст в сообщении?

Да.

-- Initialization DROP TABLE IF EXISTS "status"; CREATE TABLE "status" ("id" INT NOT NULL, "name" TEXT NOT NULL); CREATE INDEX ON status(id); INSERT INTO "status" SELECT id, 'some-value' as name FROM generate_series(1, 184) t(id); -- Transaction 1 BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; SET enable_seqscan TO off; SELECT * FROM status WHERE id = 1; -- Transaction 2 BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; SET enable_seqscan TO off; SELECT * FROM status WHERE id = 2; -- Transaction 2 UPDATE "status" SET name = 'changed' WHERE id = 2 -- OK; COMMIT -- OK; -- Transaction 1 INSERT INTO status (id, name) VALUES (1, 'some-value'); -- OK COMMIT -- OK; ------------- ------------- ------------- -- Initialization DROP TABLE IF EXISTS "status"; CREATE TABLE "status" ("id" INT NOT NULL, "name" TEXT NOT NULL); CREATE INDEX ON status(id); INSERT INTO "status" SELECT id, 'some-value' as name FROM generate_series(1, 185) t(id); -- Transaction 1 BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; SET enable_seqscan TO off; SELECT * FROM status WHERE id = 1; -- Transaction 2 BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; SET enable_seqscan TO off; SELECT * FROM status WHERE id = 2; -- Transaction 2 UPDATE "status" SET name = 'changed' WHERE id = 2 -- OK; COMMIT -- OK; -- Transaction 1 INSERT INTO status (id, name) VALUES (1, 'some-value'); -- could not serialize access due to read/write dependencies among transactions

это ужасно, на телефоне вообще невозможно, лучше скрин)

увеличение на 1 чего? счетчика в последовательности?

Не умеете пользоваться телефоном — не читайте на телефоне, делов-то.

что именно в данном контексте означает "умение" пользоваться телефоном?

Например, чтобы телеграм достаточно комфортно форматировал показанный текст.

и как это сделать в телеграм? чтобы он мог "комфортно форматировать" текст в приложении на айфоне?

Ой, да ладно. Текст или лезет в экран в ширину или нет. У меня не лезет и я с телефона не пытаюсь даже читать код. Зачем большой код смотреть с телефона — мне неведомо.

может мы просто "не умеем пользоваться телефоном", думаю он научит, и всем станет хорошо

А чё там учиться? С компа надо код смотреть/копипастить/проверять. Картинки такого кода не нужны.

с компом все понятно, я исхожу из заявления про телефон. С картинкой мне проще например понять код. Или вам важно только то, что комфортно лично вам?

Да успокойся уже.

Пока что моё предположэние — что в первом случае происходит HOT UPDATE (поскольку первая страница ещё не заполнена), соответственно, этот update не трогает индэкс и не меняет его заблокированную первую страницу. Во втором случае — для HOT UPDATE в первой страницэ нет места, соответственно, происходит проверка блокировок.

Я думаю, что настолько безрукий айтишник, что он можэт лишь страдать по поводу того, что ЕГО ЛИЧНАЯ показывалка текстов показывает их на ЕГО ЛИЧНОМ устройстве ещё хужэ, чем рандомная картинка с этим текстом с интэрнета — низачем не нужэн в техническом чятике. ЗЫ И да, жду бана, тем более что наконец надо поработать бы сегодня.

А, недописал — для HOT UPDATE нет места, соответственно, меняется индэкс и происходит проверка блокировок (которые делаются по этому индэксу).

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

До 23:39 UTC+7

Спасибо за наводку. Проверю позже и отпишусь

24" монитор к телефону подключаете и смотрите... и клавиатуру 20"... ;)

По идее, тут в первом случае (HOT) update T2 попадает на ту же страницу, а во втором — новые записи (как UPDATE T2, так и INSERT T1) попадают на новую страницу таблицы — эта ситуация обрабатывается особым образом, и может вызывать false positives, что и происходит. > Получается, если поиграться с fillfactor таблицы, то ошибка может появляться/пропадать, правильно? Да. Но на то, что подобные исключения будут происходить детерминированно в production, вообще рассчитывать не стоит (слишком много факторов влияет — последовательность транзакций; то, куда (в т.ч. в индексах) попадают записи... наличие ресурсов, наконец).