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

Re: pg_stop_backup does not complete

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_stop_backup does not complete
Date: 2010-02-24 07:46:31
Message-ID: 1266997591.3752.5870.camel@ebony (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, 2010-02-23 at 17:46 -0800, Josh Berkus wrote:
> On 2/23/10 10:58 AM, Simon Riggs wrote:
> > So I don't see this as something that needs fixing for 9.0. There is
> > already too much non-essential code there, all of which needs to be
> > tested. I don't think adding in new corner cases to "help" people makes
> > any sense until we have automated testing that allows us to rerun the
> > regression tests to check all this stuff still works.
> So, you're going to personally field the roughly 10,000 bug reports we
> get on pgsql-general about this behaviour?  24/7?

> The fact that we ran into this issue on the *first* day of testing the
> new alpha4 is indicative of how common it will be -- it is not a corner
> case, it is a common setup error which will affect probably 20% of new
> users who try 9.0.  And new users are going to panic when they can't
> shut down postgresql, not just test for issues.
> Any situation where postgresql cannot be safely shut down because of a
> common setup mistake (typoing an archive_command) is, IMNSHO, not
> something we can release with.

It's not a common setup mistake. Nothing changed in this release and
this has never been reported before.

The behaviour to wait for pg_stop_backup() was added by user request.
The behaviour for shutdown to wait for pg_stop_backup() was also added
by user request.

Your mistake was not typoing an archive_command, it was not correctly
testing that what you had done was actually working. The fix is to read
the manual and correct the typo. Shutting down the server after failing
to configure it is not likely to be a normal reaction to experiencing an
error in configuration. Better docs might help you, but I doubt it.

ISTM you should collect test reports, then analyse and prioritise them.
This rates pretty low for me: low severity, low frequency.

(If new users panic when they can't do shutdown the server, they
probably won't like smart shutdown very much either.)

 Simon Riggs 

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-02-24 08:11:26
Subject: Re: Re: [COMMITTERS] pgsql: Move documentation of all recovery.conf option to a new chapter.
Previous:From: Simon RiggsDate: 2010-02-24 07:31:25
Subject: Re: [COMMITTERS] pgsql: Move documentation of all recovery.conf option to a new chapter.

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