Re: Fixing WAL instability in various TAP tests
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andrew Dunstan <andrew@dunslane.net>,
Mark Dilger <mark.dilger@enterprisedb.com>,
Noah Misch <noah@leadboat.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-09-28T02:20:12Z
Lists: 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
Commits
-
Fix instability in contrib/bloom TAP tests.
- cf26a8d8a75f 13.5 landed
- cea5624f6a23 14.1 landed
- 6bc6bd47cf71 15.0 landed
- 2d8a8b18fe5a 12.9 landed
-
Re-enable contrib/bloom's TAP tests.
- 7d1aa6bf1c27 15.0 landed