Re: 9.2.3 crashes during archive recovery

From: Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: 9.2.3 crashes during archive recovery
Date: 2013-02-14 16:24:11
Message-ID: CA+CSw_uRWL8WbXKps6a6u-nm2zCp2NtNwEGX6xk+r7u6GOJY0A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Feb 13, 2013 10:29 PM, "Heikki Linnakangas" <hlinnakangas(at)vmware(dot)com>
wrote:
> Hmm, I just realized a little problem with that approach. If you take a
base backup using an atomic filesystem backup from a running server, and
start archive recovery from that, that's essentially the same thing as
Kyotaro's test case.

Coincidentally I was wondering about the same thing when I was reviewing
our slave provisioning procedures. There didn't seem to be any
communication channel from pg_stop_backup for the slave to know when it was
safe to allow connections.

Maybe there should be some mechanism akin to backup label to communicate
the minimum recovery point? When the min recovery point file exists the
value inside it is used, when the recovery point is reached the file is
removed. pg_basebackup would just append the file to the archive. Custom
backup procedures could also use it to communicate the necessary WAL
location.

--
Ants Aasma

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2013-02-14 16:32:07 Re: proposal or just idea for psql - show first N rows from relation backslash statement
Previous Message Stephen Frost 2013-02-14 16:03:10 Re: proposal or just idea for psql - show first N rows from relation backslash statement