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

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-17 08:49:21
Message-ID: 4E4B8091.6030300@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 16.08.2011 04:10, Fujii Masao wrote:
> On Thu, Aug 11, 2011 at 1:34 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> 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 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.
>
> We need to skip checking whether we've reached the end backup location
> only when the server crashes while base backup using pg_start_backup. Right?

Yes.

> We can do this by *not* initializing ControlFile->backupStartPoint if the server
> is doing crash recovery and backupEndRequired is false. What about the attached
> patch?

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 in that case, which is what always happens without
this patch anyway. Committed this to 9.1, but kept master as it was.

(sorry for the delay, I wanted to fix the bogus comment as soon as I saw
it, but needed some time to ponder the rest of the patch)

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jun Ishiduka 2011-08-17 08:59:37 Re: Online base backup from the hot-standby
Previous Message Simon Riggs 2011-08-17 07:42:11 Re: A note about hash-based catcache invalidations