Date: Tue, 10 Jan 2006 18:09:51 -0600
From: "Jim C. Nasby" <jnasby@pervasive.com>
To: Mark Kirkwood <markir@paradise.net.nz>
Cc: pgsql-patches@postgresql.org, pgsql-docs@postgresql.org
Subject: Re: [PATCHES] Summary table trigger example race condition
Message-ID: <20060111000951.GQ3902@pervasive.com>
References: <20060105213645.GY43311@pervasive.com>
	<43BDC132.90007@paradise.net.nz>
	<20060106030415.GL43311@pervasive.com>
	<43BDE812.5000103@paradise.net.nz>
	<43C0833D.4040607@paradise.net.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43C0833D.4040607@paradise.net.nz>
User-Agent: Mutt/1.5.11

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@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461