Re: cleanup patches for incremental backup
От | Nathan Bossart |
---|---|
Тема | Re: cleanup patches for incremental backup |
Дата | |
Msg-id | 20240314210010.GA3056455@nathanxps13 обсуждение исходный текст |
Ответ на | Re: cleanup patches for incremental backup (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: cleanup patches for incremental backup
|
Список | pgsql-hackers |
On Wed, Jan 24, 2024 at 12:05:15PM -0600, Nathan Bossart 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; I've attached a short patch for fixing this overflow risk. Specifically, it limits wal_summary_keep_time to INT_MAX / SECS_PER_MINUTE, just like log_rotation_age. I considering checking for overflow when we subtract the keep-time from the result of time(2), but AFAICT there's only a problem if time_t is unsigned, which Wikipedia leads me to believe is unusual [0], so I figured we might be able to just wait this one out until 2038. > Otherwise, I think we'll probably need to add some additional logging to > figure out what is happening... Separately, I suppose it's probably time to revert the temporary debugging code adding by commit 5ddf997. I can craft a patch for that, too. [0] https://en.wikipedia.org/wiki/Unix_time#Representing_the_number -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Вложения
В списке pgsql-hackers по дате отправления: