Re: pg_stop_backup does not complete - Mailing list pgsql-hackers

From Greg Smith
Subject Re: pg_stop_backup does not complete
Date
Msg-id 4B86B40B.1040700@2ndquadrant.com
Whole thread Raw
In response to Re: pg_stop_backup does not complete  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark wrote:
> 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?
>   

This is in the area I mentioned I'd proposed a patch to improve not too 
long ago.  The archiver doesn't tell anyone anything about what it's 
doing right now, or even save its state information.  I made a proposal 
for making the bit it's currently working on (or just finished, or both) 
visible not too long ago:  
http://archives.postgresql.org/message-id/4B4FEA18.5080705@2ndquadrant.com

The main content for that was tracking disk space, which wandered into a 
separate discussion, but it would be easy enough to use the information 
that intends to export ("what archive file is currently being 
processed?") and print that in the error message too.  Makes it easy 
enough for people to infer the command is failing if the same segment 
number shows up every time in that message.

I didn't finish that only because the CF kicked off and I switched out 
of new development to review.  Since this class of error keeps popping 
up, I could easily finish that patch off by next week and see if it 
helps here.  I thought it was a long overdue bit of monitoring to add to 
the database anyway, just never had the time to work on it before.

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

When I tested this myself, a smart shutdown hung every time, while a 
fast one blew right through the problem--matching what's described in 
the manual.  Josh suggested at one point he might have seen a situation 
where fast shutdown wasn't sufficient to work around this and an 
immediate one was required.  Certainly possible that happened for an as 
yet unknown reason--I've seen plenty of situations where fast shutdown 
didn't work--but I haven't been able to replicate it.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: pg_stop_backup does not complete
Next
From: Josh Berkus
Date:
Subject: Re: Streaming rep - why log shipping is necessary?