Re: Replaceing records
От | Jan Wieck |
---|---|
Тема | Re: Replaceing records |
Дата | |
Msg-id | 3F5EB74F.5010708@Yahoo.com обсуждение исходный текст |
Ответ на | Re: Replaceing records (Ron Johnson <ron.l.johnson@cox.net>) |
Ответы |
Re: Replaceing records
|
Список | pgsql-general |
Ron Johnson wrote: > On Fri, 2003-09-05 at 08:29, Jan Wieck wrote: >> It was not meant against anyone in person and I agree that nested >> transactions and/or catchable exceptions and continuing afterwards is >> usefull and missing in PostgreSQL. What Stephan and Richard where >> actually discussing was more like emulating the REPLACE INTO, and I was >> responding to that. >> >> However, even with nested transactions and exceptions and all that, your >> problem will not be cleanly solvable. You basically have 2 choices, >> trying the INSERT first and if that fails with a duplicate key then do >> the UPDATE, or try the UPDATE first and if no rows got hit do an INSERT. >> Now if 2 concurrent transactions do try the UPDATE they can both not >> find the row and do INSERT - one has a dupkey error. But if you try to >> INSERT and get a duplicate key, in the time between you get the error >> and issue the UPDATE someone else can issue a DELETE - the row is gone >> and your UPDATE will fail. > > SERIALIZABLE transactions will solve this. Sure will they. Care to elaborate a bit about the side effects of SERIALIZABLE? I mean semantics AND performance wise ... people tend to use suggestions like this without thinking (about the consequences). Jan :-T -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-general по дате отправления: