On 12/11/2014 04:21 PM, Marco Nenciarini wrote:
Il 11/12/14 12:38, Andres Freund ha scritto:
On December 11, 2014 9:56:09 AM CET, Heikki Linnakangas
<hlinnakan...@vmware.com> wrote:
On 12/11/2014 05:45 AM, Andres Freund wrote:
Yeah. I was not able to reproduce this, but I'm clearly missing
something, since both you and Sergey have seen this happening. Can you
write a script to reproduce?
Not right now, I only have my mobile... Its quite easy though. Create a
pg-basebackup from a standby. Create a recovery.conf with a broken primary
conninfo. Start. Shutdown. Fix conninfo. Start.
Just tested it. There steps are not sufficient to reproduce the issue on
a test installation. I suppose because, on small test datadir, the
checkpoint location and the redo location on the pg_control are the same
present in the backup_label.
To trigger this bug you need to have at least a restartpoint happened on
standby between the start and the end of the backup.
you could simulate it issuing a checkpoint on master, a checkpoint on
standby (to force a restartpoint), then copying the pg_control from the
standby.
This way I've been able to reproduce it.
Ok, got it. I was able to reproduce this by using pg_basebackup
--max-rate=1024, and issuing "CHECKPOINT" in the standby while the
backup was running.
Yeah, I agree with Andres' plan to relax the check, to also allow
DB_SHUTDOWNED_IN_RECOVERY state.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
