Re: Fixing WAL instability in various TAP tests - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fixing WAL instability in various TAP tests
Date
Msg-id 2801531.1632795612@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fixing WAL instability in various TAP tests  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Fixing WAL instability in various TAP tests
Re: Fixing WAL instability in various TAP tests
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> On Mon, Sep 27, 2021 at 04:19:27PM -0400, Tom Lane wrote:
>> I tried the same thing (i.e., re-enable bloom's TAP test) on my laptop
>> just now, and it passed fine.  The laptop is not exactly the same
>> as longfin was in 2018, but it ought to be close enough.  Not sure
>> what to make of that --- maybe the failure is only intermittent,
>> or else we fixed the underlying issue since then.

> Honestly, I have no idea what change in the backend matters here.  And
> it is not like bloom has changed in any significant way since d3c09b9.

I went so far as to check out 03faa4a8dd on longfin's host, and I find
that I cannot reproduce the failure shown at

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin&dt=2018-11-25+23%3A59%3A03

So that's the same hardware, and identical PG source tree, and different
results.  This seems to leave only two theories standing:

1.  It was a since-fixed macOS bug.  (Unlikely, especially if we also saw
it on other platforms.)

2.  The failure manifested only in the buildfarm, not under manual "make
check".  This is somewhat more plausible, especially since subsequent
buildfarm script changes might then explain why it went away.  But I have
no idea what the "subsequent script changes" might've been.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Jaime Casanova
Date:
Subject: Re: Identify missing publications from publisher while create/alter subscription.
Next
From: Justin Pryzby
Date:
Subject: Re: typos (and more)