Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Дата
Msg-id YprTEev9lz5NBbxZ@paquier.xyz
обсуждение исходный текст
Ответ на Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set  (Andres Freund <andres@anarazel.de>)
Ответы Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set  (Michael Paquier <michael@paquier.xyz>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch
Следующее
От: Sandro Santilli
Дата:
Сообщение: Re: [PATCH] Support % wildcard in extension upgrade filenames