From: | Tom Allison <tom(at)tacocat(dot)net> |
---|---|
To: | Harpreet Dhaliwal <harpreet(dot)dhaliwal01(at)gmail(dot)com> |
Cc: | Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Duplicate Unique Key constraint error |
Date: | 2007-07-11 10:24:35 |
Message-ID: | D985E6C3-0D3F-480E-B8F6-459486A05C55@tacocat.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-odbc |
On Jul 10, 2007, at 3:09 PM, Tom Lane wrote:
>
> "Harpreet Dhaliwal" <harpreet(dot)dhaliwal01(at)gmail(dot)com> writes:
>> Transaction 1 started, saw max(dig_id) = 30 and inserted new
>> dig_id=31.
>> Now the time when Transaction 2 started and read max(dig_id) it
>> was still 30
>> and by the time it tried to insert 31, 31 was already inserted by
>> Transaction 1 and hence the unique key constraint error.
>
> This is exactly why you're recommended to use sequences (ie serial
> columns) for generating IDs. Taking max()+1 does not work, unless
> you're willing to lock the whole table and throw away vast amounts of
> concurrency.
I wonder how SQL server is handling this? Are they locking the table?
I realize it's off-topic, but I'm still curious.
Sequences are your friend. they come in INT and BIGINT flavors, but
BIGINT is a lot of rows.
Can set set Sequences to automatically rollover back to zero?
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2007-07-11 12:06:53 | Re: Day of week vs. Language |
Previous Message | Dave Page | 2007-07-11 08:19:49 | Re: [GENERAL] pgpass.conf |
From | Date | Subject | |
---|---|---|---|
Next Message | Zlatko Matic | 2007-07-11 12:15:02 | odbc parameters |
Previous Message | Eric E | 2007-07-10 21:58:54 | Re: Problem getting sequences under 8.02.03.00 driver |