On Tue, Aug 04, 2015 at 02:21:16PM +0900, Michael Paquier wrote:
> >> On Tue, Jul 28, 2015 at 5:57 PM, Christoph Berg <myon@debian.org> wrote:
> >> > for something between 10% and 20% of the devel builds for apt.postgresql.org
> >> > (which happen every 6h if there's a git change, so it happens every few days),
> >> > I'm seeing this:
> In test case 2, the failure happens to be that the standby did not
> have the time to replicate the database beforepromotion that has been
> created on the master. One possible explanation for this failure is
> that the standby has been promoted before all the WAL needed for the
> tests has been replayed, hence we had better be sure that the
> replay_location of the standby matches pg_current_xlog_location()
> before promotion.
> Perhaps the attached patch helps?
Thanks. In light of your diagnosis, I can reliably reproduce the failure by
injecting a sleep into XLogSendPhysical(). Your patch fixes the problem, but
it adds wal_receiver_status_interval (= 10s) stalls, doubling
src/bin/pg_rewind/t/001_basic.pl runtime on a fast system. (The standby
applies the final WAL quickly, then sleeps for wal_receiver_status_interval
before notifying the master.) The standby will apply any written, unapplied
WAL during promotion. Therefore, I plan to commit the attached
performance-neutral variant of your patch.
