http://habrahabr.ru/post/231213/#comment_7818389

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

например


-- работает явно "неатомарно", что просто проверяется запуском 2-х транзакций, конкурирующих за 1 запсиь, пока не потребуешь явной очереди в первом же предложении стейтмента (иначе очередь собирается на 2-м, а в temp_table "припозднившихся транзакций" -- "неконсистентные", в неком смысле, данные):




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

-- поправьте меня, если я не прав.
-- или кто-то предложит простой тест, подтверждающий проблемность реализации upsert, предложенной по ссылке ?

PhoinixНе ладно и не проехали.
Нагадил - будь добр, убери за собой.

Если рандомно писать слова, то иногда будет получаться связный текст, но очень редко, в основном же - набор слов.

Внимательно читаем суть вопроса, если надо идем по ссылке (впрочем основная часть темы по ссылке о другом).

"проехали" -- в том смысле, что не спрашиваем "ты что дядя, дурак?"
-- что очень хотелось спросить, но я сдержался невероятным усилием, ога.


читаем действительно внимательно:
авторпроверки: в обоих твоих примерах получил "ERROR: duplicate key" даже не прибегнув к транзакции

" мои " примеры -- это update c предварительной обработкой этих же записей в CTE. Только полный идиот мог получить на них key-violation, не апдейтя ключей. (но вот не хотелось с порога ставить очевидный диагноз, но пришлось)

я привел "свои" примеры из другого случая, но тоже на тему того, что CTE "не атомарно" (не имеет единого снапшота, и одну и ту же запись может видеть в разных частях CTE на разные моменты времени. Для идиотов конечно надо всё расписать по полочкам ["связный текст"], но от идиотов ответов и не ожидали)

т.ч. веди, пжалста, себя прилично, пока тебя явно не разоблачаюд.



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

(да и для получения unique-violation в технике, предлагаемой по ссылке, обязательно нужна конкуренция за id между транзакциями разных сессий)

Phoinixqwwq" мои " примеры -- это update c предварительной обработкой этих же записей в CTE. Только полный идиот мог получить на них key-violation, не апдейтя ключей. (но вот не хотелось с порога ставить очевидный диагноз, но пришлось)


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

Ну ок.
дон не читает, очевидно.
или что-то вдумывает своё, глупоко личнойе.

"мои" -- это про апдейт (см тег SQL в моём посте -- их там аккурат 2)

"по ссылке" -- это не "мои".

Phoinix,

они могут писать что угодно, но апдейт полюбому встанет в очередь за конкурирующим, и будет производится над актуальной (т.е. отпущенной коммитом/роллбаком конкурента) записью. А вот "темп тейбл" будет, как показывает практика, заполнена по состоянию на начало транзакции (если мы не устроим [FOR UPDATE] очередь уже на ней - при входе на сложносоставной WITH).


Другое дело, что отдельные стейтменты того же WITH при отборах "не видят" изменений сделанных предыдущими стейтментами того же самого with (изображают поведение repeatable read, но без проверки на repeated, и без выброса violation уровня изоляции repeatable read, если запись изменилась к этому моменту ).
о чем они и хотели сообщить.
Но апдейтят они таки актуальную версию, а не версию на начало "снапшота" [== "из снапшота"] (если таки они апдейтят неактуальную версию записиписи -- срочно свяжитесь с разработчиками, и объясните им, что они не правы).

т.е. я видимо неверно тут притянул словцо "снапшот", надо как-то иначе выражовываццо. ну да ладно -- умный поймет,