Re: pg_stop_backup does not complete

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_stop_backup does not complete
Date: 2010-02-25 15:08:29
Message-ID: 407d949e1002250708p71bc870blf45ac9547c8a9a75@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 24, 2010 at 11:14 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
> Right.  I'm pointing out that production and "trying out 9.0 for the
> first time" are actually different circumstances, and we need to be able
> to handle both gracefully.  Since, if people have a bad experience
> trying it out for the first time, we'll never *get* to production.

Fwiw if it's not clear what's going on when you're trying out
something carefully for the first time it's 10x worse if you're stuck
in a situation like this when you have people breathing down your neck
yelling about how they're losing money for every second you're down.

In an ideal world it would be best if pg_stop_backup could actually
print the error status of the archiving command. Is there any way for
it to get ahold of the fact that the archiving is failing?

And do we have closure on whether a "fast" shutdown is hanging? Or was
that actually a smart shutdown?

Perhaps "smart" shutdown needs to print out what it's waiting on
periodically as well, and suggest a fast shutdown to abort those
transactions.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-02-25 15:10:41 Re: Recent vendor SSL renegotiation patches break PostgreSQL
Previous Message Magnus Hagander 2010-02-25 14:59:53 Re: Recent vendor SSL renegotiation patches break PostgreSQL