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

From Mark Dilger
Subject Re: Fixing WAL instability in various TAP tests
Date
Msg-id 193AC968-C348-4D81-88BC-384560F87500@enterprisedb.com
Whole thread Raw
In response to Re: Fixing WAL instability in various TAP tests  (Noah Misch <noah@leadboat.com>)
Responses Re: Fixing WAL instability in various TAP tests  (Mark Dilger <mark.dilger@enterprisedb.com>)
List pgsql-hackers

> On Sep 25, 2021, at 9:00 AM, Noah Misch <noah@leadboat.com> 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.

In the first draft of my email to Tom, I had language about my inartful crafting of my original post that led Noah to
respondas he did....  I couldn't quite figure out how to phrase that without distracting from the main point.  I don't
thinkyou were (much) offended, but my apologies for any perceived fingerpointing. 

I also don't have a problem with your idea of testing in the build farm with some animals having the gucs set to
minimumvalues and some to maximum and so forth.  I like that idea generally, though don't feel competent to predict how
muchwork that would be to maintain, so I'm just deferring to Tom's and your judgement about that. 

My inartful first post was really meant to say, "here is a problem that I perceive about tap tests vis-a-vis wal files,
dopeople disagree with me that this is a problem, and would patches to address the problem be welcome?"    I took Tom's
responseto be, "yeah, go ahead", and am mostly waiting for the weekend to be over to see if anybody else has anything
tosay about it. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: rand48 replacement
Next
From: Daniel Gustafsson
Date:
Subject: Re: OpenSSL 3.0.0 compatibility