Re: Enforcing that all WAL has been replayed after restoring from backup - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Enforcing that all WAL has been replayed after restoring from backup
Date
Msg-id 14347.1312998328@sss.pgh.pa.us
Whole thread Raw
In response to Re: Enforcing that all WAL has been replayed after restoring from backup  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Enforcing that all WAL has been replayed after restoring from backup
Re: Enforcing that all WAL has been replayed after restoring from backup
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Hmm, that's not possible for the 'tar' output, but would work for 'dir' 
> output. Another similar idea would be to withhold the control file in 
> memory until the end of backup, and append it to the output as last. The 
> backup can't be restored until the control file is written out.

> That won't protect from more complicated scenarios, like if you take the 
> backup without the -x flag, and copy some but not all of the required 
> WAL files manually to the pg_xlog directory. But it'd be much better 
> than nothing for 9.1.

Maybe we're overcomplicating this.  What about changing pg_basebackup to
print a message when the backup is completely sent/received?  People
would get used to that quickly, and would know to be suspicious if they
didn't see it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https
Next
From: Robert Haas
Date:
Subject: Re: Enforcing that all WAL has been replayed after restoring from backup