On Wed, Nov 12, 2014 at 12:12 PM, Josh Berkus <josh@agliodbs.com> wrote:
> 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.
I'm not sure what's going on here, but keep in mind that when you
restart the replica, it's going to back up to the most recent
restartpoint and begin replication from there, not from the point it
was at when you shut down.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company