Обсуждение: 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.
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?
--
Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
732.331.1324
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: > 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 > "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. HarrisTo: SuvarnaSent: Tuesday, February 28, 2006 8:56 PMSubject: Re: [HACKERS] bug in 7.3.2Are 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