Horton

Re: 001_rep_changes.pl stalls

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
Cc: pgsql-hackers@postgresql.org
Date: 2020-04-14T01:45:16Z
Lists: pgsql-hackers 
Noah Misch <noah@leadboat.com> writes:
> This seems to have made the following race condition easier to hit:
> https://www.postgresql.org/message-id/flat/20200206074552.GB3326097%40rfd.leadboat.com
> https://www.postgresql.org/message-id/flat/21519.1585272409%40sss.pgh.pa.us

Yeah, I just came to the same guess in the other thread.

> While I don't think that indicates anything wrong with the fix for $SUBJECT,
> creating more buildfarm noise is itself bad.  I am inclined to revert the fix
> after a week.  Not immediately, in case it uncovers lower-probability bugs.
> I'd then re-commit it after one of those threads fixes the other bug.  Would
> anyone like to argue for a revert earlier, later, or not at all?

I don't think you should revert.  Those failures are (just) often enough
to be annoying but I do not think that a proper fix is very far away.

			regards, tom lane

Commits

  1. In caught-up logical walsender, sleep only in WalSndWaitForWal().

  2. Revert "When WalSndCaughtUp, sleep only in WalSndWaitForWal()."

  3. Add a wait_for_catchup() before immediate stop of a test master.

  4. When WalSndCaughtUp, sleep only in WalSndWaitForWal().