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

From Andrew Dunstan
Subject Re: Fixing WAL instability in various TAP tests
Date
Msg-id 0feea754-5c77-ca83-8369-d73c21f1cbe0@dunslane.net
Whole thread Raw
In response to Re: Fixing WAL instability in various TAP tests  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 9/27/21 10:20 PM, Tom Lane wrote:
> 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.
>
>             


Nothing I can think of.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From:
Date:
Subject: RE: (LOCK TABLE options) “ONLY” and “NOWAIT” are not yet implemented
Next
From: Peter Eisentraut
Date:
Subject: Re: verify_heapam for sequences?