From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Avoiding overflow in timeout-related calculations |
Date: | 2012-11-18 20:14:24 |
Message-ID: | 20121118201424.GC1325@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-11-18 20:21:34 | Re: Avoiding overflow in timeout-related calculations |
Previous Message | Jeff Davis | 2012-11-18 20:04:30 | Re: Enabling Checksums |