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
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 |