From: | chenhj <chjischj(at)163(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: 32 bit libpq fail to connecting when set a very large "connect_timeout" value |
Date: | 2014-10-21 16:09:04 |
Message-ID: | 5e02241f.e1dd.1493378083f.Coremail.chjischj@163.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tom
Thanks for your response!
>That's a pretty darn silly setting, wouldn't you agree?
In practice, yes.
And the manual of PG also does not say how large value can be set to "connect_timeout" , It cannot be even call it a "bug"
But sometimes it maybe useful to know the the value range of "connect_timeout".
If without this problem we can say 2~2^31,but now ...
>I don't care for this "fix" because it assumes that all current and future
>time_t's are positive. On 32-bit machines that would break in 2038 ...
Currently PG has assumed time_t's are positive, didn't it?
static int
pqSocketPoll(int sock, int forRead, int forWrite, time_t end_time)
{
...
if (end_time == ((time_t) -1))
timeout_ms = -1;
else
{
time_tnow = time(NULL);
if (end_time > now)
...
}
>And you'd still not have dealt with PGCONNECT_TIMEOUT > 2^31, which arguably is another "bug"
>case here.
In my test when PGCONNECT_TIMEOUT > 2^31, atoi() will always return 2^31.
inttimeout = atoi(conn->connect_timeout);
Best Regards
Chen Huajun
From | Date | Subject | |
---|---|---|---|
Next Message | John R Pierce | 2014-10-21 16:59:02 | Re: 32 bit libpq fail to connecting when set a very large "connect_timeout" value |
Previous Message | michel | 2014-10-21 11:40:40 | BUG #11734: The "<<=" operator on "inet" values does not return the expected result. |