| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Melanie Plageman <melanieplageman(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Subject: | Re: Why clearing the VM doesn't require registering vm buffer in wal record |
| Date: | 2026-05-01 17:30:38 |
| Message-ID: | CA+TgmoZVSTTR9wa6zNV_j0A6mZvg=xm9X1pWZh7dty1_GcE+uQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, May 1, 2026 at 12:58 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> 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.
Fair enough.
> > 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.
Oh, yeah, OK, as long as CI will capture it, that WFM.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2026-05-01 18:10:45 | Re: Fix race condition in XLogLogicalInfo and ProcSignal initialization. |
| Previous Message | Andrew Dunstan | 2026-05-01 17:26:51 | Re: Add errdetail() with PID and UID about source of termination signal |