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 or flat)
Thread:
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           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


In response to

Responses

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-2014 The PostgreSQL Global Development Group