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: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Bernd Helmle <mailings(at)oopsware(dot)de>,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-12 08:07:17
Message-ID: 4BC2D4B5.9090400@cybertec.at (view raw or flat)
Thread:
Lists: pgsql-hackers
Martijn van Oosterhout írta:
> On Sat, Apr 10, 2010 at 02:36:41PM +0200, Boszormenyi Zoltan 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?
>>     
>
> Nope, because on a normal shutdown it writes out the actual value. When
> you say "immediate" you mean "right now, don't bother with anything not
> important", like for example gaps in sequences. You're essentially
> crashing the DB.
>
> Have a ncie day,
>   

OK, thanks for the info.

-- 
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
http://www.postgresql.at/


In response to

pgsql-hackers by date

Next:From: Fujii MasaoDate: 2010-04-12 09:06:21
Subject: Re: testing HS/SR - 1 vs 2 performance
Previous:From: Fujii MasaoDate: 2010-04-12 06:48:58
Subject: Re: testing hot standby

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