Re: Improve error detections in TAP tests by spreading safe_psql - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Improve error detections in TAP tests by spreading safe_psql
Date
Msg-id 9693.1567003408@sss.pgh.pa.us
Whole thread Raw
In response to Improve error detections in TAP tests by spreading safe_psql  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Improve error detections in TAP tests by spreading safe_psql  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> This is a follow-up of the discussion which happened here after Tom
> has committed fb57f40:
> https://www.postgresql.org/message-id/20190828012439.GA1965@paquier.xyz
> I have reviewed the TAP tests, and we have much more spots where it
> is better to use PostgresNode::safe_psql instead PostgresNode::psql so
> as the test dies immediately if there is a failure on a query which
> should never fail.

After a brief review of node->psql calls in the TAP tests, I'm
of the opinion that what we should do is revert fb57f40 and instead
change PostgresNode::psql so that on_error_die defaults to 1, then
fix the *very* small number of callers that need it to be zero.
Otherwise we're just going to be fighting this same fire forevermore.
Moreover, that's going to lead to a much smaller patch.

> Attached are the spots I have found.  Any thoughts or opinions?

Well, for instance, you missed SSLServer.pm, in which every single
one of the psql calls is wrong.

If we go this route we'd have to back-patch the change, else it'd
be a serious hazard for test case back-patching.  But the buildfarm
would, more or less by definition, find any oversights --- so that
doesn't scare me much.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: psql - improve test coverage from 41% to 88%
Next
From: Alvaro Herrera
Date:
Subject: Re: assertion at postmaster start