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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
