Reducing logs produced by TAP tests running pg_regress on crash - Mailing list pgsql-hackers

From Michael Paquier
Subject Reducing logs produced by TAP tests running pg_regress on crash
Date
Msg-id YrP6ZRXITYWhpVrl@paquier.xyz
Whole thread Raw
Responses Re: Reducing logs produced by TAP tests running pg_regress on crash  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Hi all,
(Thomas and Andres in CC.)

Andres has complained a couple of days ago about the quantity of logs
that can be fed into the TAP tests running pg_regress:
https://www.postgresql.org/message-id/20220603195318.qk4voicqfdhlsnoh@alap3.anarazel.de

This concerns the TAP tests of pg_upgrade, as well as
027_stream_regress.pl, where a crash while running the tests would
show a couple of megs worth of regression.diffs.  Most of the output
generated does not make much sense to have in this case, and the
parallel schedule gives a harder time to spot the exact query involved
in the crash (if that's a query) while the logs of the backend should
be enough to spot what's the problem with the PIDs tracked.

One idea I got to limit the useless output generated is to check the
status of the cluster after running the regression test suite as
restart_on_crash is disabled by default in Cluster.pm, and avoid any
follow-up logic in these tests if the cluster is not running anymore,
as of the attached.

Thoughts?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Add header support to text format and matching feature
Next
From: Amit Kapila
Date:
Subject: Re: tablesync copy ignores publication actions