On 11/07/2014 02:03 PM, Josh Berkus wrote:
> But, like I said, there's a serviceable workaround.
Some update on this. We've seen a problem in production with this setup
which I can't reproduce as a test case, but which may jog Heikki's
memory for something to fix.
1. Recover master to 2014-11-10 12:10:00
2. Recover replica to 2014-11-10 12:10:00, with pause_at_recovery_target
3. reconfigure recovery.conf for streaming replication and restart the replica
4. get a fatal error for replication, because the replica is ahead of the master on timeline1
What *appears* to be happening is that the pause_at_recovery_target,
followed by the restart, on the replica causes it to advance one commit
on timeline 1. But *not all the time*; this doesn't happen in my
pgbench-based tests.
There's a workaround for the user (they just restore the replica to 5
minutes earlier), but I'm thinking this is a minor bug somewhere.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
