Thread

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

    Andres Freund <andres@anarazel.de> — 2026-05-01T16:58:41Z

    Hi,
    
    On 2026-05-01 12:41:49 -0400, Robert Haas wrote:
    > 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.
    
    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