From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: cleanup patches for incremental backup |
Date: | 2024-01-24 19:08:08 |
Message-ID: | CA+TgmobWwfMpog9Yz=krBT1=sobGzWNxuEiCXg4Hh92fNOMHJw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 24, 2024 at 1:05 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> There might be an overflow risk in the cutoff time calculation, but I doubt
> that's the root cause of these failures:
>
> /*
> * Files should only be removed if the last modification time precedes the
> * cutoff time we compute here.
> */
> cutoff_time = time(NULL) - 60 * wal_summary_keep_time;
>
> Otherwise, I think we'll probably need to add some additional logging to
> figure out what is happening...
Where, though? I suppose we could:
1. Change the server code so that it logs each WAL summary file
removed at a log level high enough to show up in the test logs.
2. Change the TAP test so that it prints out readdir(WAL summary
directory) at various points in the test.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2024-01-24 19:23:39 | Re: dblink query interruptibility |
Previous Message | Pavel Stehule | 2024-01-24 18:59:11 | Re: Schema variables - new implementation for Postgres 15 |