From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Subject: | Reducing logs produced by TAP tests running pg_regress on crash |
Date: | 2022-06-23 05:30:13 |
Message-ID: | YrP6ZRXITYWhpVrl@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
tap-regress-reduce.patch | text/x-diff | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2022-06-23 06:12:46 | Re: tablesync copy ignores publication actions |
Previous Message | Julien Rouhaud | 2022-06-23 04:46:46 | Re: Add header support to text format and matching feature |