Обсуждение: bug in 7.3.2

Поиск
Список
Период
Сортировка

bug in 7.3.2

От
"Suvarna"
Дата:
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.


Re: bug in 7.3.2

От
"Jonah H. Harris"
Дата:
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

Re: bug in 7.3.2

От
Tom Lane
Дата:
"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


Re: bug in 7.3.2

От
Christopher Kings-Lynne
Дата:
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.
> 



Re: bug in 7.3.2

От
"Suvarna"
Дата:
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



Re: bug in 7.3.2

От
"Suvarna"
Дата:
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 -----
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

Re: bug in 7.3.2

От
Michael Fuhr
Дата:
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


Re: bug in 7.3.2

От
"Jaime Casanova"
Дата:
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