Re: Minor changes to Recovery related code - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: Minor changes to Recovery related code
Date
Msg-id 460D9478.30505@phlo.org
Whole thread Raw
In response to Re: Minor changes to Recovery related code  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: Minor changes to Recovery related code
Re: Minor changes to Recovery related code
List pgsql-hackers
Simon Riggs wrote:
> On Fri, 2007-03-30 at 16:34 -0400, Tom Lane wrote:
>> "Simon Riggs" <simon@2ndquadrant.com> writes:
>>> 2. pg_stop_backup() should wait until all archive files are safely
>>> archived before returning
>> Not sure I agree with that one.  If it fails, you can't tell whether the
>> action is done and it failed while waiting for the archiver, or if you
>> need to redo it.
> 
> There's a slight delay between pg_stop_backup() completing and the
> archiver doing its stuff. Currently if somebody does a -m fast straight
> after the pg_stop_backup() the backup may be unusable.
> 
> We need a way to plug that small hole.
> 
> I suggest that pg_stop_backup() polls once per second until
> pg_xlog/archive_status/LOG.ready disappears, in which case it ends
> successfully. If it does this for more than 60 seconds it ends
> successfully but produces a WARNING.

I fear that ending sucessfully despite having not archived all wals
will make this feature less worthwile. If a dba knows what he is
doing, he can code a perfectly safe backup script using 8.2 too.
He'll just have to check the current wal position after pg_stop_backup(),
(There is a function for that, right?), and wait until the corresponding
wal was archived.

In realitly, however, I feare that most people will just create a script
that does 'echo "select pg_stop_backup | psql"' or something similar.
If they're a bit more carefull, they will enable ON_ERROR_STOP, and check
the return value of pgsql. I believe that those are the people who would
really benefit from a pg_stop_backup() that waits for archiving to complete.
But they probably won't check for WARNINGs.

Maybe doing it the other way round would be an option?
pg_stop_backup() could wait for the archiver to complete forever, but
spit out a warning every 60 seconds or so "WARNING: Still waiting
for wal archiving of wal ??? to complete". If someone really wants
a 60-second timeout, he can just use statement_timeout.

Anyway, just my 0.02 eurocents, maybe I'm totally mistaken about the
postgresql dba's out there...

greetings, Florian Pflug


pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: Minor changes to Recovery related code
Next
From:
Date:
Subject: Last minute mini-proposal (I know, I know) for PQexecf()