Re: Why clearing the VM doesn't require registering vm buffer in wal record - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Why clearing the VM doesn't require registering vm buffer in wal record
Date
Msg-id CA+TgmoYFughWFgiyq-csQkB6k9EorqED0AWTDu8+OVKFX_r_wA@mail.gmail.com
Whole thread
In response to Re: Why clearing the VM doesn't require registering vm buffer in wal record  (Melanie Plageman <melanieplageman@gmail.com>)
Responses Re: Why clearing the VM doesn't require registering vm buffer in wal record
List pgsql-hackers
On Thu, Apr 30, 2026 at 5:44 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> I added a TAP test that does something like Andres' incremental backup
> repro but tests more variations. Because init_from_backup() runs
> pg_combinebackup with the --debug flag, the log output is very verbose
> (i.e. every single copied file is logged). I suggest we turn it off by
> default in tests. I included a patch that does that. It isn't required
> to commit my test, but my test does produce 5000 lines of regression
> log output which seems...not ideal.

In my experience, it's pretty much impossible to debug a pg_basebackup
failure with incremental backup without the --debug option. Like,
you'll just have no idea where things went wrong. So I am cautious
about this, but I also understand that we run the tests a lot of times
on a lot of branches on a lot of machines, and so 5000 lines of output
that seems like no big deal in isolation may start to add up to a big
deal when you multiply it out.

So I feel like if your reasoning here is "this is using too many
resources and we can't afford it," that's fair enough, and we'll just
have to accept that if it starts failing we'll have to turn this back
on to have any idea what the problem is. If your reasoning is more
like "well I don't want all this output," I don't really think that's
a great reason -- if it ever fails, you will.

Another possible approach could be to direct the output to a temporary
file. At the end of the test run, if no tests failed, remove the file.
If there were any failures, copy that file's contents into the log.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Refactor: allow pg_strncoll(), etc., to accept -1 length for NUL-terminated cstrings.
Next
From: SATYANARAYANA NARLAPURAM
Date:
Subject: Re: Changing the state of data checksums in a running cluster