Lists: | pgsql-general |
---|
From: | db(dot)subscriptions(at)shepherdhill(dot)biz |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Serial Jumping |
Date: | 2009-01-27 04:55:48 |
Message-ID: | 20090127055548.bpcc4i3hcgs00sco@webmail.shepherdhill.biz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
Hi,
I have a table with BIG SERIAL field as Primary KEY. During high load,
entries in the BIG SERIAL field are jumped. One could see a row with
1367 and expecting the next INSERT to be 1368, one would end up
getting 1369.
Please is this normal?
Regards,
Chris
From: | Bill Moran <wmoran(at)potentialtech(dot)com> |
---|---|
To: | db(dot)subscriptions(at)shepherdhill(dot)biz |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Serial Jumping |
Date: | 2009-01-27 05:14:48 |
Message-ID: | 20090127001448.aa35061b.wmoran@potentialtech.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
db(dot)subscriptions(at)shepherdhill(dot)biz wrote:
>
> Hi,
>
> I have a table with BIG SERIAL field as Primary KEY. During high load,
> entries in the BIG SERIAL field are jumped. One could see a row with
> 1367 and expecting the next INSERT to be 1368, one would end up
> getting 1369.
>
> Please is this normal?
If transactions rollback, the serial value assigned during the rolled
back transaction is skipped. This has been discussed many times, it's
a tradeoff between losing some #s now and again and taking a huge
performance and code complexity hit to avoid it.
If you absolutely need consecutive #s, then serial is not for you and
you should implement your own method of acquiring sequential numbers.
--
Bill Moran
http://www.potentialtech.com
From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Bill Moran <wmoran(at)potentialtech(dot)com> |
Cc: | db(dot)subscriptions(at)shepherdhill(dot)biz, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Serial Jumping |
Date: | 2009-01-27 05:24:23 |
Message-ID: | 497E9A87.50305@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
Bill Moran wrote:
> db(dot)subscriptions(at)shepherdhill(dot)biz wrote:
>> Hi,
>>
>> I have a table with BIG SERIAL field as Primary KEY. During high load,
>> entries in the BIG SERIAL field are jumped. One could see a row with
>> 1367 and expecting the next INSERT to be 1368, one would end up
>> getting 1369.
>>
>> Please is this normal?
>
> If transactions rollback, the serial value assigned during the rolled
> back transaction is skipped. This has been discussed many times, it's
> a tradeoff between losing some #s now and again and taking a huge
> performance and code complexity hit to avoid it.
>
> If you absolutely need consecutive #s, then serial is not for you and
> you should implement your own method of acquiring sequential numbers.
You should also understand the several LARGE downsides to doing so. See
repeated past mailing list discussion.
--
Craig Ringer
From: | "A(dot) Kretschmer" <andreas(dot)kretschmer(at)schollglas(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Serial Jumping |
Date: | 2009-01-27 06:10:18 |
Message-ID: | 20090127061018.GA29255@a-kretschmer.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
In response to db(dot)subscriptions(at)shepherdhill(dot)biz :
> Hi,
>
> I have a table with BIG SERIAL field as Primary KEY. During high load,
> entries in the BIG SERIAL field are jumped. One could see a row with
> 1367 and expecting the next INSERT to be 1368, one would end up
> getting 1369.
>
> Please is this normal?
Yes. Because a serial can't rolled back.
Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net
From: | Devrim GÜNDÜZ <devrim(at)gunduz(dot)org> |
---|---|
To: | db(dot)subscriptions(at)shepherdhill(dot)biz |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Serial Jumping |
Date: | 2009-01-27 16:29:01 |
Message-ID: | 1233073741.15799.9.camel@laptop.gunduz.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
On Tue, 2009-01-27 at 05:55 +0100, db(dot)subscriptions(at)shepherdhill(dot)biz
wrote:
> I have a table with BIG SERIAL field as Primary KEY. During high load,
> entries in the BIG SERIAL field are jumped. One could see a row with
> 1367 and expecting the next INSERT to be 1368, one would end up
> getting 1369.
>
> Please is this normal?
Yes, but there is a way to get rid of that:
http://www.varlena.com/GeneralBits/130.php
Regards,
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org
From: | Jasen Betts <jasen(at)xnet(dot)co(dot)nz> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Serial Jumping |
Date: | 2009-02-01 10:21:22 |
Message-ID: | gm3t32$8nf$1@reversiblemaps.ath.cx |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
On 2009-01-27, db(dot)subscriptions(at)shepherdhill(dot)biz <db(dot)subscriptions(at)shepherdhill(dot)biz> wrote:
> Hi,
>
> I have a table with BIG SERIAL field as Primary KEY. During high load,
> entries in the BIG SERIAL field are jumped. One could see a row with
> 1367 and expecting the next INSERT to be 1368, one would end up
> getting 1369.
>
> Please is this normal?
if an insert that would have used 1368 failed or is in an unfinished
transaction that's entirely normal.
if you care about the value you are inserting make sure you know it as
the time it is inserted (use returning or use nextval beforehand)