=MOHAX=При конкурентном доступе совсем не обязательно, что id будут идти последовательно.
Получается, что запрос вроде как один, но по факту сначала выполнится


и только потом


?

А Вы ожидали, что будет наоборот? ;) Это и в самом деле один запрос, читаемый snapshot тут один.

=MOHAX=Правильно ли я понимаю, что в таком случае надо делать блокировку на всю таблицу и только потом выполнять INSERT?



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

https://www.postgresql.org/docs/current/static/transaction-iso.html#XACT-SERIALIZABLE

=MOHAX=К сожалению я не могу изменять уровень изоляции на Serializable...Почему?

=MOHAX=Так в том то и дело, что при конкурентном доступе последовательность нарушается.Ну тут можно и придраться и сказать, что нарушения-то тут и нет...
Сделать COMMIT второй транзакции Вам же не удастся, верно? ;)

qwwqPgSQLanonymous3
https://www.postgresql.org/docs/current/static/transaction-iso.html#XACT-SERIALIZABLE

не слушайте этого обкурка.

По себе судишь, да? Это ссылка на официальную документацию ,
которая описывает этот подход, если ты не заметил.

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

С чего ты решил, что это правильно?
Чему ты вообще тут новичков учишь?
Делать кривые БД с неконсистентыми данными?
Отказываться от гарантий ради... чего?

qwwqПричём -- разобраться лучше всего для умолчательного режима рид--коммитед
(хотя бы по той причине, что транзакционный ддл честно
отрабатывает только для этого режима изоляции).

Что-то конктреных существенных претензий к DLL я так от тебя и не слышал.

qwwqв древности для этого использовали например такие трюки,
как табличку максимумов (tablename,max_commited_id)

И сейчас используют, и в чём тут трюк? Обычная оптимизация...

qwwqи делали сначала SELECT FOR UPDATE из неё, и только
потом (когда она освобождалась предыдущим сеансом)
-- в следующем стейтменте --
INSERT INTO table1 с чтением заново значения из таблички максимумов.

А вот эта ерунда уже перпендикулярна "табличке максимумов".

qwwqтакого же типа подходы можно делать и с адвайзори локами.
Важно помнить, что они требуют дисциплины --- если кто--то
пойдет мимо такого оговорённого механизма
очереди -- он испортит всю обедню.
Ну правильно, надо же с базой побороться ради неизвестно чего, а не работой заниматься.

qwwqтак же, как если кто--то влезет с коммитедом на кухню к сериалайзебальщикам.

То это будут его, влезшего, личные проблемы. Его и только его
транзакции начнут создавать так любимую "коммитедшиками" неконсистентную окрошку. ;)

qwwqчисто философски, если клиент (или третий слой) крутится в непосредственной близости (затраты на доступ мизерны), и вы всю реализацию сложной логики выносите в него -- сериалайзебл будет оправдан -- логика на деле размажется между третим слоем и базой -- сейвпойнтики там, и все такое. но вам на затраты "взаимодействия--откатов" покласть -- сетевых затрат нет.

У меня такое впечатление, что большинство программистов СУБД почему-то уверены,
что они занимаются highload-ом, хотя ничего подобного у них и близко нет ,
и все их "оптимизации" на деле оказываются не только пустой тратой времени,
но и приводят к куче ошибок.

qwwqНо если вы минималист -- логику БД храните в БД -- то учитесь работать без откатов с клиента -- только с очередями внутри БД--ной логики, вызываемой хранимками с клиента. В пж есть много печали со сложными (объёмистыми) типами, (отсутствие передачи по ссылке -- только через копию) -- что-то из сродственного с работой со строками в жабе (буферов в пж у вас не будет) -- вот там вот всё это может сработать очень интересно. если обкурок этим занимается -- это его извиняет. но лезть в общем случае с таким решением в классическом клиент-- сервере --- это перебор
Вот, вот оно --- во всей красе. ;(
Зачем ты вообще пришёл в "мир" РСУБД, если ты одержим производительностью?
Ты вообще понимаешь, что это специализированные инструменты, у которых
есть определённые свойства и чёткое назначение (ты вообще знаешь, какое?).
И использовать их стоит только тогда, когда эти свойства и возможности
для кого-то настолько важны , что он готов за это заплатить
производительностью, и заплатить дорого .

ocp_dba_rhcePgSQLanonymous3пропущено...
У меня такое впечатление, что большинство программистов СУБД почему-то уверены,
что они занимаются highload-ом, хотя ничего подобного у них и близко нет ,
и все их "оптимизации" на деле оказываются не только пустой тратой времени,
но и приводят к куче ошибок.
.
Этот товарищ, последние 4 года и занимался highload-ом на 500Тб базе с 10000 TPS,
прилетом wraparaund-a и другими приключениями.

Ну что ж, если этой базой занимается он, надеюсь, корректность данных там не очень важна. ;)
Я же говорю про большинство программистов СУБД, у которых таких баз (ни по размеру,
ни, главное, по нагрузке) и близко нет . И учить их таким вещам никакого смысла нет --- всё,
что они от этого получат, это потерянное время и горсть трудноуловимых ошибок.
Это именно та ситуация, о которой вот эта цитата:
Premature optimization is the root of all evil -- Donald Knuth

ocp_dba_rhceЕсли в ваши жизненные планы входит позаниматься чем-то посерьезней, чем БД класса
записная книжка объемом не больше десятка Гб, то стоит вчитаться в его трудно
перевариваемые посты.
"Записная книжка" тут ни причём совершенно.
IMHO, большинство БД сейчас находятся в диапазоне нескольких сотен Гб, и среди них немало "серьёзных".
Дело-то в том, что объём данных (хранимых в СУБД), о многих объектах реального мира
вместе с ростом мощности компьютеров не растёт .

Вот, к примеру, объём данных в БД ERP областной розничной сети, торгующей
стройматериалами (где немало номенклатур, проводок, и разнообразных
бизнес-процессов, информация о которых хранится в той же базе), за 10 лет работы
составил всего лишь ~ 400 Гб.

qwwqPgSQLanonymous3,
на заборе тоже много чо пишуд

Тоже личный опыт участия? ;)

qwwqт.е. если в доке написано, "как правильно работать в сериалайзебле", это ещё не означает , что именно "в сериалайзебле -- работать правильно"

То есть, до описываемых там преимуществ ты так и не дочитал?
qwwqоткрыл 2 сессии. в одной бы начал не рид комитед транзакцию [мы проверяли на рипитебл риде -- просто шальная мысль была, что наше партицирование в автономиях не совместимо с рипитебл], и смотрел за появлением объектов, не существовавших до начала его транзы. там много радости, типа гистерезиса на селектах из системных в зависимости от порядка выполнения dml и выборок. и т.п.. мне это очень скучно и грустно перепроверять. -- я был "фшоки", ага. в полном.
И было это, наверное, лет 10 назад, когда в PostgreSQL даже SERIALIZABLE не было, да? ;)
Я к тому, что развивается он быстро, и то, что было фактом 5 лет назад, может быть сейчас совсем не так.
Кстати, мне помнится, что использование SnapshotAny для выборок из системных таблиц
упорно устраняли, и, возможно, устранили совсем...

qwwqвы не проверили -- т.ч. "печально я смотрю на ваше по колено"
Согласен, полной и всесторонней проверки транзакционного DDL я не производил ---
приходится верить документации, а что поделаешь. :(

qwwqт.е. то, чем я занимался -- не аргумент
То, чем кто-то занимался --- в общем случае, не аргумент.

qwwqбыло это месяца полтора тому. или 2.
как из ушата окатило, ага
Не удержался, проверил. Да, всё так и есть, как ты говоришь.
И вообще, похоже на то, что "общепринятое" значение "термина"
transactional DDL --- не ACID, а только AD. ;(

qwwqа про то, что пишут эти бракоделы --- я как-то (года два тому) на отписку тома лейна
кому--то по поводу инвалидизации (вернее --её отсутствии) планов при дропе или
удалении из иерархии партиций наткнулся, тоже ещё тот перец оказался. хотя казалось бы
-- пять минут накидать тест кейс. да озадачится репланированием. а ведь
авторитетнейший гурья в сообществе.печаль. и там тоже --"воз и ныне там"

Ты про это вот, что ли?
https://www.postgresql.org/message-id/flat/19015.1305087444@sss.pgh.pa.us
Если да, то там есть и test case, и отреагировал он адекватно ---
"да, это недостаток, но переписывать надо много".
Но да, "воз и ныне там". :(

qwwqт.ч. читать там этих козликов, когда они за философию -- себя не уважать.
вот вы себя и не уважили, хехе.

Мне это пока не было критично .
А так да, это там бывает, и меня тоже напрягает. Но если продолжать использовать
PostgreSQL, остаётся только "Мыши плакали, кололись...". ;)

qwwqSerializable transactions are the best performance choice for some environments.
какое слово some в этом предложении вызывает у вас затруднение ?

Это: performance . Вместе с тем, что твоя им одержимость не
даёт тебе права давать дурные советы нормальным людям. ;)
Как и то, что это вообще не является ключевым из описываемых там преимуществ.

qwwqPgSQLanonymous3,
нормальные люди всю жисть на умолчательном рид-коммитеде сидят, и он им не жметИз какого пальца ты высосал эту "статистику", интересно?

qwwqэто только задроты, которые дисциплине работе с коммитедем не обучены, И эта "дисциплина" состоит в основном в "а хрен с ним, авось прокатит", да?

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

Чего-чего? Какое ещё "сторонее" решение? Что, для изменения уровня
изоляции какое-то сторонее расширение надо ставить, что ли? ;)
qwwqвместо того, чтобы единожды освоить работу со строго очередным доступом к разделяемому ресурсу
А, то есть это прям серебряная пуля, и все уровни выше READ COMMITTED
придумали какие-то недоучки, а надо-то всего "единожды освоить работу",
и они сразу станут не нужны, и всё будет консистетно, да?

qwwq(а совсем таки не про оптимизацию тот паттерн, как нам тут обкурки подбрасывают)

Ты о чём, вообще?

qwwqпро лейна замнём -- не все собеседники вкуривают чем отписка отличается
от работы. хотя и обкурились по саоме небалуйсо. не в коня корм.

Во-первых, не суди по себе, а во-вторых, твоя "критика" Tom Lane очень
напоминает басню про Слона и Моську.

qwwqPgSQLanonymous3,
нормальным кодерам в версионнике нужны 2 уровня
-- умолчательный рид коммитед, чтобы нормально конкурентно писать ( с явными очередями, если ресурс разделяемый)
-- и снапшот -- чтобы собирать консистентный отчет.
всё.

Ага, всё, вот корректности данных и конец. :(
Видно, жизненный принцип таких "нормальных" кодеров "write once and run away".

qwwqсериалайзебл придуман для дрочеров , не умеющих написать 2 слова подряд без того, чтобы не обделаться.

SERIALIZABLE придуман для нормальных людей, а не для самовлюблённых идиотов,
которые радостно пишут в базу и читают оттуда мусор вместо данных.
Вот скажи мне, ты у себя в базе один разрабатываешь?
А если нет, то откуда все эти люди знают, какой ресурс у вас в данный
момент разделяемый, а какой нет?
А нормальным людям (сюрприз!) знать этого вообще не надо ,
наше дело всего лишь корректно написать только свою процедуру/транзакцию, и всё.

qwwqк этому прилагается набор паттернов организации очередей [доступа к разделяемому ресурсу] там, где они необходимы.
вот собственно весь джентельменский набор, достаточный для писания базёнок любого уровня
Да-да, "у нас есть такие приборы. Но мы вам о них не расскажем."

qwwqа рукожопым обкуркам остаётся только тыкать незнакомым людям,

Да ты просто восхитительный умница! ;)

qwwqи рассказывать басни про сторонних мега гурьёв, отписки которых вполне в количествах даны нам в ощущения :
https://www.postgresql.org/message-id/2684.1242058486@sss.pgh.pa.us]https://www.postgresql.org/message-id/2684.1242058486@sss.pgh.pa.us
Ну и где ты там увидел отписку, конкретно? Ты thread дальше-то читал, кстати?