Re: Why clearing the VM doesn't require registering vm buffer in wal record

Hi,

On 2026-05-01 12:41:49 -0400, Robert Haas wrote:
> On Thu, Apr 30, 2026 at 5:44 PM Melanie Plageman
> <melanieplageman(at)gmail(dot)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.

Well, right now the regress_log* files that involve combining backups are so
long that it's hard to find the actual stuff that's happening - and it's worse
with the test Melanie is proposing because it runs a few iterations of
combining backups. So I think it's not universal that you'd want it.

> 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.

I think that's probably the better direction. I'd not even include it
directly into regress_log, just put it alongside it, like we have the server
logs etc.

Greetings,

Andres Freund