Re: Race condition in recovery? - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Race condition in recovery?
Date
Msg-id 20210602130131.GB98498@rfd.leadboat.com
Whole thread Raw
In response to Re: Race condition in recovery?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Jun 01, 2021 at 04:45:52PM -0400, Robert Haas wrote:
> On Fri, May 28, 2021 at 2:05 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote:
> > Agreed. I often annoyed by a long-lasting TAP script when I wanted to
> > do one of the test items in it. However, I was not sure which is our
> > policy here, consolidating all related tests into one script or having
> > separate scripts containing tests up to a "certain" number or a set of
> > tests that would take a certain time, or limiting by number the of
> > lines.  I thought that we are on the first way as I have told several
> > times to put new tests into an existing script.
> 
> Different people might have different opinions about this, but my
> opinion is that when it's possible to combine the test cases in a way
> that feels natural, it's good to do. For example if I have two tests
> that require the same setup and teardown but do different things in
> the middle, and if those things seem related, then it's great to set
> up once, try both things, and tear down once. However I don't support
> combining test cases where it's just concatenating them one after
> another, because that sort of thing seems to have no benefit. Fewer
> files in the source tree is not a goal of itself.

I agree, particularly for the recovery and subscription TAP suites.  When one
of those tests fails on the buildfarm, it's often not obvious to me which log
messages are relevant to the failure.  Smaller test files simplify the
investigation somewhat.



pgsql-hackers by date:

Previous
From: "Joel Jacobson"
Date:
Subject: Re: security_definer_search_path GUC
Next
From: Matthias van de Meent
Date:
Subject: Re: pg_stat_progress_create_index vs. parallel index builds