Skip site navigation (1) Skip section navigation (2)

Re: pg_ctl stop -m immediate on the primary server inflates sequences

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org,Hans-Juergen Schoenig <hs(at)cybertec(dot)at>
Subject: Re: pg_ctl stop -m immediate on the primary server inflates sequences
Date: 2010-04-10 12:36:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Bernd Helmle írta:
> --On 10. April 2010 09:26:41 +0200 Boszormenyi Zoltan <zb(at)cybertec(dot)at>
> wrote:
>> The above is quite reproducable, "pg_ctl stop -m immediate"
>> "usually" inflated my serial sequence, but I had two occasions
>> when not. The 69 -> 70 was one. The inflated increase is always 33:
> AFAIKS sequences are pre-logged with 32 values to WAL to avoid
> overhead. I suspect this is why you are seeing those gaps.

Then it should happen all the time, even with "-m fast" or "-m smart", no?

It seemed like my sequences have a CACHE 32 setting, which would
apply to every client that connects, runs nextval() once and disconnects.

But it didn't happen all the time, so it's not deterministic.

Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics

Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-04-10 13:02:28
Subject: Re: master in standby mode croaks
Previous:From: Joachim WielandDate: 2010-04-10 12:18:09
Subject: Re: a faster compression algorithm for pg_dump

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group