On Mon, Sep 7, 2015 at 1:16 PM, Noah Misch <noah@leadboat.com> wrote:
> 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.)
Indeed, thanks for double-checking.
> The standby will apply any written, unapplied
> WAL during promotion. Therefore, I plan to commit the attached
> performance-neutral variant of your patch.
Explaining the use of write_location. This looks fine to me. Thanks again.
--
Michael
