Re: BUG #7670: BUG #7545: Unresponsive server with error log reporting: "poll() failed: Invalid argument"

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2012-11-18 14:07:37 -0500, Tom Lane wrote:
>> Anyway, even if Linux for some reason doesn't reject negative values,
>> I think we need to limit the GUC's range so we don't try to use them.
>> Maybe you'd get sane behavior and maybe you wouldn't. I notice that
>> the Single Unix Spec doesn't specify EINVAL for negative timeout
>> values, but it also doesn't define what happens for a negative value
>> other than -1. So this is basically an unspecified case and it's
>> incumbent on us to not do it if we want portable behavior.

> I aggree that we need to do something. I just think it might be enough
> to clamp the timeout value passed to WaitLatchOrSocket to the maximum
> valid value. The rest of SysLoggerMain seems to work correctly in that
> case.

This seems a rather 64-bit-centric view of the world. If "long" is
32 bits, the value will have overflowed before it ever gets to
WaitLatch.

I'm thinking it might be reasonable to put an Assert(timeout <= INT_MAX)
into WaitLatch, since we're already asserting timeout >= 0. But adding
a run-time clamp is not sufficient to fix the problem, because if any
overflow happens it's happening upstream.

regards, tom lane