Re: Deferrable Unique Constraints
От | Greg Stark |
---|---|
Тема | Re: Deferrable Unique Constraints |
Дата | |
Msg-id | 87k6pzxvzu.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: Deferrable Unique Constraints (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Deferrable Unique Constraints
|
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> writes: > Yeah, what I've been visualizing is a list of "tentative duplicates" --- > that is, you do the immediate unique check same as now, and if it passes > (which hopefully is most of the time) then you're in the clear. I don't see how you're in the clear. If session A does an insert and it doesn't see a duplicate and doesn't commit, but then B does an insert and sees the duplicate from A and marks his tentative, and then commits, shouldn't B's commit succeed? Then when A commits shouldn't his fail? So A still has to recheck even if there was no sign of a duplicate when he inserted. Unless there's some way for B to indicate to A that his insert has become tentative then I think you have to resign yourself to checking all deferred unique constraints, not just ones that seem suspect. -- greg
В списке pgsql-hackers по дате отправления: