Re: 001_rep_changes.pl stalls

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: 001_rep_changes.pl stalls
Date: 2020-04-14 01:45:16
Message-ID: 8807.1586828716@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Noah Misch <noah(at)leadboat(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2020-04-14 01:50:39 Re: weird hash plan cost, starting with pg10
Previous Message Noah Misch 2020-04-14 01:38:49 Re: 001_rep_changes.pl stalls