Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
От | Peter Geoghegan |
---|---|
Тема | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Дата | |
Msg-id | CAM3SWZSaoiCmLLD_tez9riFVHiOfQD7J+hbBBBcaUjrSUsXdLw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
|
Список | pgsql-hackers |
On Tue, Dec 31, 2013 at 12:52 AM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: >> Are you suggesting that I lock the tuple only (say, through a special >> LockPromiseTuple() call), or lock the tuple *and* call >> XactLockTableWait() afterwards? You and Robert don't seem to be in >> agreement about which here. > > I meant the latter, ie. grab the new kind of lock first, then check if the > tuple is still there, and then call XactLockTableWait() as usual. I don't follow this either. Through what exact mechanism does the waiter know that there was a wait on the PromiseTupleInsertionLockAcquire() call, and so it should not wait on XactLockTableWait()? Does whatever mechanism you have in mind not have race conditions? -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: