On 2012-11-18 12:44:55 -0500, Tom Lane wrote:
> Igor <igorya.inscriptio@gmail.com> writes:
> > 2012/11/18 Tom Lane <tgl@sss.pgh.pa.us>
> >> I was just about to ask what you have log_rotation_age set to ...
>
> > Was:
> > log_rotation_age = 30d
>
> That's the problem then. Internally that gets converted to
> milliseconds, which'll overflow at 24-something days. Use a smaller
> value.
Nicely guessed.
> So the actual bug here is an over-optimistic maximum value for
> log_rotation_age in guc.c. After looking through all the callers of
> WaitLatch, I think the only other similar issue is for
> wal_sender_timeout, which currently is allowed to range up to INT_MAX;
> but such values seem pretty useless.
>
> I'm inclined to propose limiting both of these to the equivalent of 15
> days. Alternatively we could try to rejigger things to prevent asking
> WaitLatch to wait for more than 2^31 msec, but it's not real clear to
> me that it's worth the trouble.
In general I have no problem imposing lower limits, but it seems to be a
ugly to get errors for an invalid configuration file after a minor
version upgrade. While the wal_sender_timeout isn't really likely to be
that high I don't think the log_rotation_age one is unlikely to be set
to something in the month range, thats not an unreasonable value.
I suggest adding an Assert before the (int)timeout cast, but I guess you
already plan to do so.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
