| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: recovery_target_time and standby_mode |
| Date: | 2014-11-12 17:12:33 |
| Message-ID: | 54639501.8040700@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2014-11-12 17:15:47 | Re: pg_background (and more parallelism infrastructure patches) |
| Previous Message | Fujii Masao | 2014-11-12 17:10:36 | Re: pg_receivexlog --status-interval add fsync feedback |