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



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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to