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

Re: Clean shutdown and warm standby

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, 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>
Subject: Re: Clean shutdown and warm standby
Date: 2009-05-28 14:41:36
Message-ID: 1243521696.24860.612.camel@ebony.2ndQuadrant (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, 2009-05-28 at 17:21 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > 
> > I don't think it does, please look again. 
> Still looks ok to me. pgarch_ArchiverCopyLoop() loops until all ready 
> WAL segments have been archived (assuming no errors).

No, it doesn't now, though it did used to. line 440.

> >> Ok, we're good then I guess.
> > 
> > No, because as I said, if archive_command has been returning non-zero
> > then the archive will be incomplete.
> Yes. You think that's wrong? How would you like it to behave, then? I 
> don't think you want the shutdown to wait indefinitely until all files 
> have been archived if there's an error.

The complaint was that we needed to run a manual step to synchronise the
pg_xlog directory on the standby. We still need to do that, even after
the patch has been committed because 2 cases are not covered, so what is
the point of the recent change? It isn't enough. It *might* be enough,
most of the time, but you have no way of knowing that is the case and it
is dangerous not to check.

 Simon Riggs 
 PostgreSQL Training, Services and Support

In response to


pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2009-05-28 14:47:47
Subject: Re: User-facing aspects of serializable transactions
Previous:From: Kevin GrittnerDate: 2009-05-28 14:40:01
Subject: Re: User-facing aspects of serializable transactions

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