Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Date: 2010-02-11 17:31:54
Message-ID: 20100211173154.GD14128@oak.highrise.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-docs pgsql-hackers

* Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> [100211 12:04]:

> > But it can be a problem - without the last WAL (or at least enough of
> > it) the master switched and archived, you have no guarantee of having
> > being consistent again (I'm thinking specifically of recovering from a
> > fresh backup)
>
> You have to wait for the last WAL file required by the backup to be
> archived before starting recovery. Otherwise there's no guarantee anyway.

Right, but now define "wait for". If you pull only "half" the last WAL
(because you've accepted that you *can* have short WAL files in the
archive), you have the problem with PITR.

Is it "wait for it to be in the archive", or "wait for it to be in the
archive, and be sure that the contents satisfy some criteria".

I've always made my PITR such that "in the archive" (i.e. the first
moment a recovery can see it) implies that it's bit-for-bit identical to
the original (or at least as bit-for-bit I can assume by checking
various hashes I can afford to). I just assumed that was kind of common
practice.

I'm amazed that "partial WAL" files are every available in anyones
archive, for anyone's restore command to actually pull. I find that
scarry, and sure, probably won't regularly be noticed... But man, I'ld
hate the time I need that emergency PITR restore to be the one time when
it needs that WAL, pulls it slightly before the copy has finished (i.e.
the master is pushing the WAL over a WAN to a 2nd site), and have my
restore complete consistently...

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2010-02-11 18:08:24 Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Previous Message Heikki Linnakangas 2010-02-11 17:29:33 Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

Browse pgsql-docs by date

  From Date Subject
Next Message Tom Lane 2010-02-11 18:08:24 Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Previous Message Heikki Linnakangas 2010-02-11 17:29:33 Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2010-02-11 17:35:18 Re: Writeable CTEs and empty relations
Previous Message Heikki Linnakangas 2010-02-11 17:29:33 Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL