Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Date
Msg-id YprTEev9lz5NBbxZ@paquier.xyz
Whole thread Raw
In response to Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set  (Andres Freund <andres@anarazel.de>)
Responses Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
List pgsql-hackers
On Fri, Jun 03, 2022 at 12:53:18PM -0700, Andres Freund wrote:
> [...]

TRAP: FailedAssertion("AmIoWorkerProcess()", File: "xlog.c", Line:
4860, PID: 35325)

> regress_log_002_pg_upgrade.log includes all of 002_pg_upgrade_old_node.log and
> 002_pg_upgrade_new_node.log. The old node's log includes all pg_dump queries.

log_statement = all is the part biting here.  It does not seem like
we'd lose a lot of context even if this is made less verbose.

> Followed by many MB of diff due to
>
> === diff of /Users/admin/pgsql/src/bin/pg_upgrade/tmp_check/tmp_test_Q7GQ/dump1.sql and
/Users/admin/pgsql/src/bin/pg_upgrade/tmp_check/tmp_test_Q7GQ/dump2.sql
> === stdout ===

Something like 80~85% of the bloat comes from the diffs in your case.
Well, it is always possible to limit that to an arbitrary amount of
characters (say 50k~100k?) to still give some context, and dump the
whole in a different file outside the log/ path (aka tmp_check/), so
that the buildfarm would show a minimum amount of information, while
local failures would still have an access to everything.

Do you have any preferences?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch
Next
From: Sandro Santilli
Date:
Subject: Re: [PATCH] Support % wildcard in extension upgrade filenames