Re: Clean shutdown and warm standby - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Clean shutdown and warm standby
Date
Msg-id 1243524970.24860.645.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: Clean shutdown and warm standby  (Guillaume Smet <guillaume.smet@gmail.com>)
Responses Re: Clean shutdown and warm standby  (Guillaume Smet <guillaume.smet@gmail.com>)
List pgsql-hackers
On Thu, 2009-05-28 at 17:16 +0200, Guillaume Smet wrote:
> On Thu, May 28, 2009 at 5:02 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
> > So you check. This solves Guillaume's immediate concern. If you have a
> > suggestion for further improvements, I'm all ears.
> 
> Thanks for applying the patch.
> 
> Yes, the problem is that before this change, even with a working
> replication and a clean shutdown, you still had to replicate the last
> WAL file by hand. Personnally, I have an eye on each postgresql log
> file when I switch from one server to another so I can see if anything
> is going wrong (that said, it could be a problem with more than 2
> servers...).
> 
> This patch just fixes this problem not the other concerns and corner
> cases we might have. If we want to go further, we need to agree on
> what we want exactly and which corner cases we want to cover but it's
> probably 8.5 material at this point.

Your original post wanted to know "we are sure we have all the useful
XLog files when we perform a clean shutdown of master". The patch does
not solve the problem you stated. 

You may consider it useful, but a manual check or script execution must
still happen. 

If you feel we have moved forwards, that's good, but since no part of
the *safe* maintenance procedure has changed, I don't see that myself.
Only the unsafe way of doing it got faster.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: "Jignesh K. Shah"
Date:
Subject: Re: sun blade 1000 donation
Next
From: "Kevin Grittner"
Date:
Subject: Re: User-facing aspects of serializable transactions