| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Enforcing that all WAL has been replayed after restoring from backup |
| Date: | 2011-08-10 17:45:28 |
| Message-ID: | 14347.1312998328@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2011-08-10 17:46:50 | Re: Enforcing that all WAL has been replayed after restoring from backup |
| Previous Message | Tom Lane | 2011-08-10 17:27:18 | Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https |