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
