From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
Cc: | pgsql-patches(at)postgresql(dot)org, pgsql-docs(at)postgresql(dot)org |
Subject: | Re: [PATCHES] Summary table trigger example race condition |
Date: | 2006-01-11 00:09:51 |
Message-ID: | 20060111000951.GQ3902@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-patches |
On Sun, Jan 08, 2006 at 04:13:01PM +1300, Mark Kirkwood wrote:
> After re-examining the original code, it looks like it was not actually
> vulnerable to a race condition! (it does the UPDATE, then if not found
> will do an INSERT, and handle unique violation with a repeat of the same
> UPDATE - i.e three DML statements, which are enough to handle the race
> in this case).
What happens if someone deletes the row between the failed insert and
the second update? :)
AFAICT, example 36-1 is the only way to handle this without creating a
race condition.
> However Jim's change handles the race needing only two DML statements in
> a loop, which seems much more elegant! In addition it provides a nice
> example of the 'merge' style code shown in e.g 36-1.
What's SOP here... should I ping someone to let them know this patch
should be committed now that those who care are happy with it?
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2006-01-11 00:40:37 | Re: Summary table trigger example race condition |
Previous Message | Mark Kirkwood | 2006-01-08 03:13:01 | Re: Summary table trigger example race condition |
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2006-01-11 00:40:37 | Re: Summary table trigger example race condition |
Previous Message | Tom Lane | 2006-01-10 23:05:54 | Re: TupleDesc refcounting |