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

Re: Clean shutdown and warm standby

From: Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: Clean shutdown and warm standby
Date: 2009-05-27 21:35:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Apr 28, 2009 at 5:35 PM, Guillaume Smet
<guillaume(dot)smet(at)gmail(dot)com> wrote:
> On Tue, Apr 28, 2009 at 5:22 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> At a normal startup, the checkpoint record would be there as usual. And an
>> archive recovery starts at the location indicated by the backup label.
>> AFAICS calling RequestXLogSwitch() before CreateCheckPoint would be
>> equivalent to calling "pg_switch_xlog()" just before shutting down.
> That's what I had in mind when writing the patch but I didn't know the
> implications of this particular checkpoint.
> So moving the call before CreateCheckPoint is what I really intended
> now that I have in mind these implications and I don't know why it would be
> a problem to miss this checkpoint in the logs archived.

What do we decide about this problem?

Should we just call RequestXLogSwitch() before the creation of the
shutdown checkpoint or do we need a more complex patch? If so can
anybody explain the potential problem of this approach so we can
figure how to fix it?



In response to


pgsql-hackers by date

Next:From: Larry SilvermintzDate: 2009-05-27 21:38:39
Subject: Need 8.4 chm.
Previous:From: Caleb WeltonDate: 2009-05-27 21:25:58
Subject: Re: [PATCH] plpythonu datatype conversion improvements

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