On 2012-11-18 12:44:55 -0500, Tom Lane wrote: > Igor <igorya.inscrip...@gmail.com> writes: > > 2012/11/18 Tom Lane <t...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
