Subject: Re: duplicate key violates unique constraint
From: Csaba Nagy <nagy@ecircle-ag.com>
To: Richard Huxton <dev@archonet.com>
Cc: "ON.KG" <skyer@on.kg>,
	Postgres general mailing list <pgsql-general@postgresql.org>
In-Reply-To: <42ADAAFB.30404@archonet.com>
References: <42A95936.3060002@archonet.com>
	<20050610095655.0215752956@svr1.postgresql.org>
	<10813889593.20050613202239@on.kg>  <42AD9B9D.6080902@archonet.com>
	<1118676122.2720.24.camel@coppola.muc.ecircle.de>
	<42ADAAFB.30404@archonet.com>
Content-Type: text/plain
Message-Id: <1118678332.2720.27.camel@coppola.muc.ecircle.de>
Mime-Version: 1.0
Date: Mon, 13 Jun 2005 17:58:52 +0200
Content-Transfer-Encoding: 7bit

That would work indeed. Bit I guess the savepoint solution will be the
simplest and fastest if the OP has or can install 8.0 version.

Cheers,
Csaba.

On Mon, 2005-06-13 at 17:49, Richard Huxton wrote:
> Csaba Nagy wrote:
> > [snip]
> > 
> >>If you have more than one client, this can always happen. You have two 
> >>choices:
> >>  1. Use a lock to stop two clients interacting like this
> > 
> > 
> > This won't work unless you make all the clients serialized, or you have
> > all the ip's already inserted in the data base... you can't lock on an
> > unknown key, otherwise the locking will also need to insert, and you're
> > back to the same race condition ;-)
> 
> You can, however, have something more finely-grained than whole-table 
> locking (assuming one IP updated/inserted at a time) by filling a dummy 
> table with e.g. integers 0..255 and locking a row there based on (e.g.) 
> the last octet of your target IP.
> 
> --
>    Richard Huxton
>    Archonet Ltd