From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_rewind tap test unstable |
Date: | 2015-09-07 04:16:41 |
Message-ID: | 20150907041641.GA3105381@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)debian(dot)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.
Attachment | Content-Type | Size |
---|---|---|
pgrewind_tapfix-v2.patch | text/plain | 1.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2015-09-07 04:35:59 | Re: Reusing abbreviated keys during second pass of ordered [set] aggregates |
Previous Message | Amit Kapila | 2015-09-07 03:28:15 | Re: Waits monitoring |