From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Igor <igorya(dot)inscriptio(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #7670: BUG #7545: Unresponsive server with error log reporting: "poll() failed: Invalid argument" |
Date: | 2012-11-18 18:18:42 |
Message-ID: | 4024.1353262722@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2012-11-18 12:44:55 -0500, Tom Lane wrote:
>> 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.
Well, we have two reports of people trying such values (assuming that
#7545 actually is the same thing), and it didn't work for either of
them. I don't think it's a problem to restrict the value to something
that will work rather than fail.
If you're worried that there's somebody out there using 20 or 21 days
as log_rotation_age, I guess we could limit to INT_MAX/1000 seconds or
something just less than that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Igor | 2012-11-18 18:25:30 | Re: BUG #7670: BUG #7545: Unresponsive server with error log reporting: "poll() failed: Invalid argument" |
Previous Message | Phil Sorber | 2012-11-18 18:14:26 | Re: Prepared Statement Name Truncation |