Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

2011-08-17 Thread Heikki Linnakangas
On 17.08.2011 12:26, Fujii Masao wrote: So, in master, we should change pg_controldata.c and pg_resetxlog.c for new pg_control field "backupEndRequired"? Ah, good catch! Fixed. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-h

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

2011-08-17 Thread Fujii Masao
On Wed, Aug 17, 2011 at 5:49 PM, Heikki Linnakangas wrote: > Hmm, this behaves slightly differently, if you first try to start the > restored server without recovery.conf, stop recovery, and restart it after > adding recovery.conf. But I guess that's not a big deal, the check is simply > skipped i

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

2011-08-17 Thread Heikki Linnakangas
On 16.08.2011 04:10, Fujii Masao wrote: On Thu, Aug 11, 2011 at 1:34 AM, Heikki Linnakangas wrote: 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

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

2011-08-15 Thread Fujii Masao
On Thu, Aug 11, 2011 at 1:34 AM, Heikki Linnakangas wrote: > 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

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

2011-08-12 Thread Dimitri Fontaine
Magnus Hagander writes: >>> Or add a signal >>> handler in the pg_basebackup client emitting a warning about it? >> >> We don't have such a signal handler pg_dump either. I don't think we should >> add it. > > Hmm. I guess an aborted pg_dump will also "look ok but actually be > corrupt" (or incomp

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

2011-08-10 Thread Magnus Hagander
On Wed, Aug 10, 2011 at 19:45, Tom Lane wrote: > Heikki Linnakangas 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. T

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

2011-08-10 Thread Robert Haas
On Wed, Aug 10, 2011 at 1:45 PM, Tom Lane wrote: > Heikki Linnakangas 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.

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

2011-08-10 Thread Tom Lane
Heikki Linnakangas 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 fi

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

2011-08-10 Thread Heikki Linnakangas
On 10.08.2011 15:34, Simon Riggs wrote: On Wed, Aug 10, 2011 at 1:19 PM, Robert Haas wrote: On Wed, Aug 10, 2011 at 6:53 AM, Magnus Hagander wrote: On Wed, Aug 10, 2011 at 12:44, Heikki Linnakangas wrote: On 10.08.2011 12:29, Magnus Hagander wrote: On Tue, Aug 9, 2011 at 18:07, Tom Lane

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

2011-08-10 Thread Simon Riggs
On Wed, Aug 10, 2011 at 1:19 PM, Robert Haas wrote: > On Wed, Aug 10, 2011 at 6:53 AM, Magnus Hagander wrote: >> On Wed, Aug 10, 2011 at 12:44, Heikki Linnakangas >> wrote: >>> On 10.08.2011 12:29, Magnus Hagander wrote: On Tue, Aug 9, 2011 at 18:07, Tom Lane  wrote: > > Heikki

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

2011-08-10 Thread Robert Haas
On Wed, Aug 10, 2011 at 6:53 AM, Magnus Hagander wrote: > On Wed, Aug 10, 2011 at 12:44, Heikki Linnakangas > wrote: >> On 10.08.2011 12:29, Magnus Hagander wrote: >>> >>> On Tue, Aug 9, 2011 at 18:07, Tom Lane  wrote: Heikki Linnakangas  writes: > > On 09.08.2011 18:20, Alvaro

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

2011-08-10 Thread Magnus Hagander
On Wed, Aug 10, 2011 at 12:44, Heikki Linnakangas wrote: > On 10.08.2011 12:29, Magnus Hagander wrote: >> >> On Tue, Aug 9, 2011 at 18:07, Tom Lane  wrote: >>> >>> Heikki Linnakangas  writes: On 09.08.2011 18:20, Alvaro Herrera wrote: > > How about making the new backup_label fie

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

2011-08-10 Thread Heikki Linnakangas
On 10.08.2011 12:29, Magnus Hagander wrote: On Tue, Aug 9, 2011 at 18:07, Tom Lane wrote: Heikki Linnakangas writes: On 09.08.2011 18:20, Alvaro Herrera wrote: How about making the new backup_label field optional? If absent, assume current behavior. That's how I actually did it in the pa

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

2011-08-10 Thread Magnus Hagander
On Tue, Aug 9, 2011 at 18:07, Tom Lane wrote: > Heikki Linnakangas writes: >> On 09.08.2011 18:20, Alvaro Herrera wrote: >>> How about making the new backup_label field optional?  If absent, assume >>> current behavior. > >> That's how I actually did it in the patch. However, the problem wrt. >>

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

2011-08-10 Thread Heikki Linnakangas
On 09.08.2011 19:07, Tom Lane wrote: Heikki Linnakangas writes: On 09.08.2011 18:20, Alvaro Herrera wrote: How about making the new backup_label field optional? If absent, assume current behavior. That's how I actually did it in the patch. However, the problem wrt. requiring initdb is not

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

2011-08-09 Thread Tom Lane
Heikki Linnakangas writes: > On 09.08.2011 18:20, Alvaro Herrera wrote: >> How about making the new backup_label field optional? If absent, assume >> current behavior. > That's how I actually did it in the patch. However, the problem wrt. > requiring initdb is not the new field in backup_label,

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

2011-08-09 Thread Heikki Linnakangas
On 09.08.2011 18:20, Alvaro Herrera wrote: Excerpts from Heikki Linnakangas's message of mar ago 09 05:00:00 -0400 2011: I think this is a nice additional safeguard to have, making streamed backups more robust. I'd like to add this to 9.1, but it required an extra field to be added to the contr

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

2011-08-09 Thread Alvaro Herrera
Excerpts from Heikki Linnakangas's message of mar ago 09 05:00:00 -0400 2011: > I think this is a nice additional safeguard to have, making streamed > backups more robust. I'd like to add this to 9.1, but it required an > extra field to be added to the control file, so it would force an > initd