From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | <pgsql-hackers(at)postgresql(dot)org>, "Greg Stark" <gsstark(at)mit(dot)edu> |
Subject: | Re: Hard problem with concurrency |
Date: | 2003-02-17 05:07:31 |
Message-ID: | 024a01c2d642$7aae8b00$6500a8c0@fhp.internal |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> If you don't have a primary key already, create a unique index on the
> combination you want to be unique. Then:
>
> . Try to insert the record
> . If you get a duplicate key error
> then do update instead
>
> No possibilities of duplicate records due to race conditions. If two
people
> try to insert/update at the same time you'll only get one of the two
results,
> but that's the downside of the general approach you've taken. It's a tad
> inefficient if the usual case is updates, but certainly not less efficient
> than doing table locks.
The idea was to stop our postgres logs being spammed up with unique
constraint violation warnings....in which case your solution above is
identical to our current one. Update and if it fails, insert, except since
the row is likely to already be there - our current way will be a bit more
efficient.
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2003-02-17 05:26:23 | Non-colliding auto generated names |
Previous Message | Greg Stark | 2003-02-17 04:51:49 | Re: Hard problem with concurrency |