Re: pg_rewind tap test unstable
От | Noah Misch |
---|---|
Тема | Re: pg_rewind tap test unstable |
Дата | |
Msg-id | 20150907041641.GA3105381@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: pg_rewind tap test unstable (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: pg_rewind tap test unstable
|
Список | 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@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.
Вложения
В списке pgsql-hackers по дате отправления: