bug in 7.3.2
we are using postgresql 7.3.2 version.
We are facing a problem in nextval of sequence. The problem is as follows,
If the server shuts down abrupotly because of power failuar or any other
cause then the sequences tend to skip few numbers.
After restarting the server the nextval of sequence doest match
with the last number.
Are you caching sequences?
On 2/28/06, Suvarna <suvarnat@cygnus.stpp.soft.net> wrote:
we are using postgresql 7.3.2 version.
We are facing a problem in nextval of sequence. The problem is as follows,
If the server shuts down abrupotly because of power failuar or any other
cause then the sequences tend to skip few numbers.
After restarting the server the nextval of sequence doest match
with the last number.
--
Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
732.331.1324
"Suvarna" <suvarnat@cygnus.stpp.soft.net> writes:
We are facing a problem in nextval of sequence. The problem is as =
follows,
If the server shuts down abrupotly because of power failuar or any other
cause then the sequences tend to skip few numbers.
This is not a bug, it is the designed behavior. It's not really
different from the case of a number going unused because a transaction
does nextval() and then rolls back --- you cannot assume that the
sequence of used values has no holes, in any case.
regards, tom lane
That's not a bug it's normal behaviour.
Suvarna wrote:
Show quoted text
we are using postgresql 7.3.2 version.
We are facing a problem in nextval of sequence. The problem is as follows,
If the server shuts down abrupotly because of power failuar or any other
cause then the sequences tend to skip few numbers.
After restarting the server the nextval of sequence doest match
with the last number.
Hello Tom,
thankyou for the reply but,
actually the number which are missing are in the range of 20-30 and at the
max only 3 transactions are going on at any given point in time.
So if 3 numbers are missing then it was understood the missing numbers are
very large.
Regards,
suvarna
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Suvarna" <suvarnat@cygnus.stpp.soft.net>
Cc: <pgsql-hackers@postgresql.org>
Sent: Tuesday, February 28, 2006 9:29 PM
Subject: Re: [HACKERS] bug in 7.3.2
Show quoted text
"Suvarna" <suvarnat@cygnus.stpp.soft.net> writes:
We are facing a problem in nextval of sequence. The problem is as =
follows,
If the server shuts down abrupotly because of power failuar or any other
cause then the sequences tend to skip few numbers.This is not a bug, it is the designed behavior. It's not really
different from the case of a number going unused because a transaction
does nextval() and then rolls back --- you cannot assume that the
sequence of used values has no holes, in any case.regards, tom lane
Hello Jonah,
No we are not caching the sequence
In the transaction for the first time we use next val & then on we use curretn val.
Regards,
Suvarna
----- Original Message -----
From: Jonah H. Harris
To: Suvarna
Cc: pgsql-hackers@postgresql.org
Sent: Tuesday, February 28, 2006 8:56 PM
Subject: Re: [HACKERS] bug in 7.3.2
Are you caching sequences?
On 2/28/06, Suvarna <suvarnat@cygnus.stpp.soft.net> wrote:
we are using postgresql 7.3.2 version.
We are facing a problem in nextval of sequence. The problem is as follows,
If the server shuts down abrupotly because of power failuar or any other
cause then the sequences tend to skip few numbers.
After restarting the server the nextval of sequence doest match
with the last number.
--
Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
732.331.1324
On Wed, Mar 01, 2006 at 10:17:04AM +0530, Suvarna wrote:
actually the number which are missing are in the range of 20-30 and at the
max only 3 transactions are going on at any given point in time.
So if 3 numbers are missing then it was understood the missing numbers are
very large.
The number of transactions is irrelevant. If a single transaction
obtains 20 values from a sequence and that transaction is rolled
back, then those 20 sequence values are gone. Think of a sequence
as a generator of arbitrary unique numbers, not as a way to get
numbers guaranteed to have no gaps.
--
Michael Fuhr
On 2/28/06, Suvarna <suvarnat@cygnus.stpp.soft.net> wrote:
we are using postgresql 7.3.2 version.
As somebody pointed out, that's not a bug... but i think you must
upgrade at least to 7.3.14
even if you really found a bug nobody will fix it for 7.3.2
--
regards,
Jaime Casanova
"What they (MySQL) lose in usability, they gain back in benchmarks, and that's
all that matters: getting the wrong answer really fast."
Randal L. Schwartz