Re: Avoiding overflow in timeout-related calculations

On 2012-11-18 14:57:51 -0500, Tom Lane wrote:
> The discussion of bug #7670 showed that what's happening there is that
> if you specify a log_rotation_age of more than 25 days (2^31 msec),
> WaitLatch will sometimes be passed a timeout of more than 2^31 msec,
> leading to unportable behavior. At least some kernels will return
> EINVAL for that, and it's not very clear what will happen on others.
>
> After some thought about this, I think the best thing to do is to tweak
> syslogger.c to to clamp the requested sleep to INT_MAX msec. The fact
> that a couple of people have tried to set log_rotation_age to 30 days or
> more suggests that it's useful, so reducing the GUC's upper limit isn't
> a desirable fix. This should be an easy change since the logic in that
> loop will already behave correctly if it's woken up before the requested
> rotation time.

Cool. Agreed.

> I went looking for other timeout-related GUC variables that might have
> overoptimistic upper limits, and found these cases:
>
> [sensible stuff]

Lowering the maximum of those seems sensible to me. Anybody using that
large value for those already had a problem even if it worked.

I think at least wal_sender_timeout and wal_receiver_timeout are also
problematic.

Greetings,

Andres

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services