Re: Testing "workers launched" in expected output? Really? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Testing "workers launched" in expected output? Really?
Date
Msg-id CA+TgmoaihHZmrqpKdzFyD8AO_54Q_2WN5dnRtmcs=6o1PmczGg@mail.gmail.com
Whole thread Raw
In response to Re: Testing "workers launched" in expected output? Really?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Testing "workers launched" in expected output? Really?  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On Fri, Mar 2, 2018 at 3:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> My point is that just because it isn't falling over on
> relatively-lightly-loaded buildfarm machines doesn't mean that it won't
> fall over in other environments.

It doesn't mean it will, either.

> I should think that your recent experience with postgres_fdw (which is
> evidently still broken, BTW, see rhinoceros) would have convinced you
> that environmentally dependent regression test results are something to
> studiously avoid.

I suspect the problem with the test is that it's testing for a plan
that is only slightly better than the next-best plan, and so it takes
very little to push it over the edge.  That's sort of an environment
issue, but it's not exactly the same thing you're worried about here.

> We have enough trouble with unforeseen test deltas;
> putting in tests that have a blatantly obvious failure mechanism is
> just taunting the software gods.  Who tend to take their revenge in
> unpleasant ways.
>
> If you insist on actual failures, perhaps I'll go set up about four
> concurrently-scheduled animals on prairiedog's host, and wait to see
> what happens ...

I will be curious to see the results of that experiment.  Unless you
press the machine so hard that fork() starts returning EAGAIN, I don't
see why that should cause this to fail.  And if you do that, then it's
going to fail far beyond the ability of suppressing Workers Launched
to cover the problem up.  However, it's certainly possible that you've
thought of some failure mode that I've missed, or that there is one
which neither of us has considered.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Next
From: Bruce Momjian
Date:
Subject: Re: Cached/global query plans, autopreparation