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

Re: Hot standby, recovery infra

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot standby, recovery infra
Date: 2009-01-30 14:55:46
Message-ID: 498314F2.8030005@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Ok, here's an attempt to make shutdown work gracefully.

Startup process now signals postmaster three times during startup: first 
when it has done all the initialization, and starts redo. At that point. 
postmaster launches bgwriter, which starts to perform restartpoints when 
it deems appropriate. The 2nd time signals when we've reached consistent 
recovery state. As the patch stands, that's not significant, but it will 
be with all the rest of the hot standby stuff. The 3rd signal is sent 
when startup process has finished recovery. Postmaster used to wait for 
the startup process to exit, and check the return code to determine 
that, but now that we support shutdown, startup process also returns 
with 0 exit code when it has been requested to terminate.

The startup process now catches SIGTERM, and calls proc_exit() at the 
next WAL record. That's what will happen in a fast shutdown. Unexpected 
death of the startup process is treated the same as a backend/auxiliary 
process crash.

InitXLogAccess is now called in IsRecoeryProcessingMode() as you suggested.

Simon Riggs wrote:
> On Thu, 2009-01-29 at 19:20 +0200, Heikki Linnakangas wrote:
>> Heikki Linnakangas wrote:
>>> It looks like if you issue a fast shutdown during recovery, postmaster 
>>> doesn't kill bgwriter.
>> Hmm, seems like we haven't thought through how shutdown during 
>> consistent recovery is supposed to behave in general. Right now, smart 
>> shutdown doesn't do anything during consistent recovery, because the 
>> startup process will just keep going. And fast shutdown will simply 
>> ExitPostmaster(1), which is clearly not right.
> 
> That whole area was something I was leaving until last, since immediate
> shutdown doesn't work either, even in HEAD. (Fujii-san and I discussed
> this before Christmas, briefly).
> 
>> I'm thinking that in both smart and fast shutdown, the startup process 
>> should exit in a controlled way as soon as it's finished with the 
>> current WAL record, and set minSafeStartPoint to the current point in 
>> the replay.
> 
> That makes sense, though isn't required.
> 
>> I wonder if bgwriter should perform a restartpoint before exiting? 
>> You'll have to start with recovery on the next startup anyway, but at 
>> least we could minimize the amount of WAL that needs to be replayed.
> 
> That seems like extra work for no additional benefit.
> 
> I think we're beginning to blur the lines between review and you just
> adding some additional stuff in this area. There's nothing to stop you
> doing further changes after this has been committed. We can also commit
> what we have with some caveats also, i.e. commit in pieces.
> 


-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

Attachment: recovery-infra-531534c.patch
Description: text/x-diff (57.7 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2009-01-30 15:41:28
Subject: Re: [PATCH] Space reservation v02
Previous:From: Andrew DunstanDate: 2009-01-30 14:52:03
Subject: Re: mingw check hung

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