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

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: 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-10 16:34:23
Message-ID: 4E42B30F.90309@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10.08.2011 15:34, Simon Riggs wrote:
> On Wed, Aug 10, 2011 at 1:19 PM, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
>> On Wed, Aug 10, 2011 at 6:53 AM, Magnus Hagander<magnus(at)hagander(dot)net> wrote:
>>> On Wed, Aug 10, 2011 at 12:44, Heikki Linnakangas
>>> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>>> On 10.08.2011 12:29, Magnus Hagander wrote:
>>>>>
>>>>> On Tue, Aug 9, 2011 at 18:07, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>>>>
>>>>>> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> 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, it's the new
>>>>>>> field in the control file.
>>>>>>
>>>>>> Yeah. I think it's too late to be fooling with pg_control for 9.1.
>>>>>> Just fix it in HEAD.
>>>>>
>>>>> Should we add a note to the documentation of pg_basebackup in 9.1
>>>>> telling people to take care about the failure case?
>>>>
>>>> Something like "Note: if you abort the backup before it's finished, the
>>>> backup won't be valid" ? That seems pretty obvious to me, hardly worth
>>>> documenting.
>>>
>>> I meant something more along the line of that it looks ok, but may be corrupted.
>>
>> Yeah. I'm frankly pretty nervous about shipping 9.1 with this
>> problem, but note that I don't have a better idea. I'd favor making
>> pg_basebackup emit a warning or maybe even remove the backup if it's
>> aborted midway through.
>
> I don't understand why we need to change pg_control for this?
>
> Why can't we just add a line to backup_label as the first action of
> pg_basebackup and then updated it the last action to show the backup
> set is complete?

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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2011-08-10 16:37:13 gcc 4.6 warnings in HEAD?
Previous Message Andrew Dunstan 2011-08-10 15:25:31 Re: longstanding mingw warning