Re: Fixing WAL instability in various TAP tests
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-09-25T16:20:39Z
Lists: pgsql-hackers
Noah Misch <noah@leadboat.com> writes: > On Sat, Sep 25, 2021 at 08:20:06AM -0700, Mark Dilger wrote: >> You may be right, but the conversation about "all possible settings" was >> started by Noah. > You wrote, "I would expect tests which fail under legal alternate GUC settings > to be hardened to explicitly set the GUCs as they need, rather than implicitly > relying on the defaults." I read that as raising the general principle, not > just a narrow argument about max_wal_size. As did I. > We can discontinue talking about > the general principle and focus on max_wal_size. It is worth stopping to think about whether there are adjacent settings that need similar treatment. In general, it seems like "premature discarding of WAL segments" is something akin to "premature timeout" errors, and we've got a pretty aggressive policy about preventing those. There are a lot of settings that I'd *not* be in favor of trying to be bulletproof about, because it doesn't seem worth the trouble; but perhaps this one is. 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