Hi, On 2026-05-01 12:41:49 -0400, Robert Haas wrote: > On Thu, Apr 30, 2026 at 5:44 PM Melanie Plageman > <[email protected]> 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
