Thread: 32 bit libpq fail to connecting when set a very large "connect_timeout" value

SGksYWxsCgoKVGhpcyBhIGJ1ZyByZXBvcnQuCgoKMSlUaGUgcHJvYmxlbQpXaGVuIHNldCBhIHZl
cnkgbGFyZ2UgdmFsdWUoc3VjaCBhcyAyMTQ3NDgzNjQ3IHdoaWNoIGlzIHRoZSBtYXhpbXVtIG9m
IGludCApIHRvIGNvbm5lY3RfdGltZW91dCxhbmQgdGhlbiBjb25uZWN0IHRvIHRoZSBiYWNrZW5k
IHVzaW5nIDMyIGJpdCBwc3FsLCBhIHRpbWVvdXQgd2lsbCBvY2N1ci4KRm9yIGV4YW1wbGU6CgoK
W2NoZW5oakBub2RlMiB+XSQgZXhwb3J0IFBHQ09OTkVDVF9USU1FT1VUPTIxNDc0ODM2NDcKW2No
ZW5oakBub2RlMiB+XSQgcHNxbApwc3FsOiB0aW1lb3V0IGV4cGlyZWQKCgpXaGlsZSBpdCdzIE9L
IHdoZW4gdXNpbmcgNjQgYml0IHBzcWwuCgoKW2NoZW5oakBub2RlMiB+XSQgZXhwb3J0IFBHQ09O
TkVDVF9USU1FT1VUPTIxNDc0ODM2NDcKW2NoZW5oakBub2RlMiB+XSQgcHNxbApwc3FsICg5LjIu
OCkKVHlwZSAiaGVscCIgZm9yIGhlbHAuCgoKcG9zdGdyZXM9IyBccQoKCgoKMilUaGUgcmVhc29u
CkkgbG9va2VkIGludG8gdGhlIHNvdXJjZSBjb2RlLCBhbmQgZm91bmQgdGhlIHJlYXNvbiBpcyBh
IGRhdGEgb3ZlcmZsb3cgd2hlbiBjYWxjdWxhdGluZyBjb25uZWN0aW5nJ3MgZmluaXNoX3RpbWUg
YXMgdGhlIGZvbGxvd2luZy4KCgpzcmNcaW50ZXJmYWNlc1xsaWJwcVxmZS1jb25uZWN0LmM6CnN0
YXRpYyBpbnQKY29ubmVjdERCQ29tcGxldGUoUEdjb25uICpjb25uKQp7ClBvc3RncmVzUG9sbGlu
Z1N0YXR1c1R5cGUgZmxhZyA9IFBHUkVTX1BPTExJTkdfV1JJVElORzsKdGltZV90ZmluaXNoX3Rp
bWUgPSAoKHRpbWVfdCkgLTEpOwoKCmlmIChjb25uID09IE5VTEwgfHwgY29ubi0+c3RhdHVzID09
IENPTk5FQ1RJT05fQkFEKQpyZXR1cm4gMDsKCgovKgoqIFNldCB1cCBhIHRpbWUgbGltaXQsIGlm
IGNvbm5lY3RfdGltZW91dCBpc24ndCB6ZXJvLgoqLwppZiAoY29ubi0+Y29ubmVjdF90aW1lb3V0
ICE9IE5VTEwpCnsKaW50dGltZW91dCA9IGF0b2koY29ubi0+Y29ubmVjdF90aW1lb3V0KTsKCgpp
ZiAodGltZW91dCA+IDApCnsKLyoKKiBSb3VuZGluZyBjb3VsZCBjYXVzZSBjb25uZWN0aW9uIHRv
IGZhaWw7IG5lZWQgYXQgbGVhc3QgMiBzZWNzCiovCmlmICh0aW1lb3V0IDwgMikKdGltZW91dCA9
IDI7Ci8qIGNhbGN1bGF0ZSB0aGUgZmluaXNoIHRpbWUgYmFzZWQgb24gc3RhcnQgKyB0aW1lb3V0
ICovCmZpbmlzaF90aW1lID0gdGltZShOVUxMKSArIHRpbWVvdXQ7Ly8gSW4gMzIgYml0IGFwcGxp
Y2F0aW9uIHRpbWVfdCBpcyBhIDMyIGJpdCwgd2hlbiAgdGltZW91dCBpcyB2ZXJ5IGxhcmdlLCBk
YXRhIG92ZXJmbG93IHdpbGwgb2NjdXIgYW5kIGZpbmlzaF90aW1lIGJlY2FtZSBhIG5lZ2F0aXZl
IHZhbHVlLgogICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e
Xl5eXl5eXgp9Cn0KLi4uCn0KCgoKCk9mIGNvdXJzZSB0aGlzIGlzIGEgaW5mcmVxdWVuY2UgYnVn
LCBidXQgaSB0aGluayBpdCBzaG91bGQgYmUgZml4ZWQsIHN1Y2ggYXMgdGhlIGZvbGxvd2luZyht
YXkgYmUgdGhlcmUncyBiZXR0ZXIgd2F5IHRvIGZpeCBpdCkuCgoKZmluaXNoX3RpbWUgPSB0aW1l
KE5VTEwpICsgdGltZW91dDsKPT0+CmZpbmlzaF90aW1lID0gdGltZShOVUxMKSArIHRpbWVvdXQ7
CmlmKGZpbmlzaF90aW1lIDwgKCh0aW1lX3QpIDApKQp7CiAgIGZpbmlzaF90aW1lID0gKCh0aW1l
X3QpIC0xKTsKfQoKCgoKQmVzdCBSZWdhcmRzCkNoZW4gSHVhanVu

chenhj <chjischj@163.com> writes:
> [chenhj@node2 ~]$ export PGCONNECT_TIMEOUT=2147483647

That's a pretty darn silly setting, wouldn't you agree?

> finish_time = time(NULL) + timeout;
> if(finish_time < ((time_t) 0))
> {
>    finish_time = ((time_t) -1);
> }

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 ...
unless time_t is redefined as unsigned 32-bit, in which case the test
becomes useless.

It might be possible to develop a test for overflow that would work
regardless of the width or signedness of time_t, but ISTM the work would
be vastly out of proportion to the benefit.  And you'd still not have
dealt with PGCONNECT_TIMEOUT > 2^31, which arguably is another "bug"
case here.

            regards, tom lane

VG9tCgoKVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlIQoKCj5UaGF0J3MgYSBwcmV0dHkgZGFybiBz
aWxseSBzZXR0aW5nLCB3b3VsZG4ndCB5b3UgYWdyZWU/CgoKSW4gcHJhY3RpY2UsIHllcy4KQW5k
IHRoZSBtYW51YWwgb2YgUEcgYWxzbyBkb2VzIG5vdCBzYXkgaG93IGxhcmdlIHZhbHVlIGNhbiBi
ZSBzZXQgdG8gImNvbm5lY3RfdGltZW91dCIgLCBJdCBjYW5ub3QgYmUgZXZlbiBjYWxsIGl0IGEg
ImJ1ZyIKQnV0IHNvbWV0aW1lcyBpdCBtYXliZSB1c2VmdWwgdG8ga25vdyB0aGUgdGhlIHZhbHVl
IHJhbmdlIG9mICJjb25uZWN0X3RpbWVvdXQiLgpJZiB3aXRob3V0IHRoaXMgcHJvYmxlbSB3ZSBj
YW4gc2F5IDJ+Ml4zMSxidXQgbm93IC4uLgoKCj5JIGRvbid0IGNhcmUgZm9yIHRoaXMgImZpeCIg
YmVjYXVzZSBpdCBhc3N1bWVzIHRoYXQgYWxsIGN1cnJlbnQgYW5kIGZ1dHVyZQo+dGltZV90J3Mg
YXJlIHBvc2l0aXZlLiAgT24gMzItYml0IG1hY2hpbmVzIHRoYXQgd291bGQgYnJlYWsgaW4gMjAz
OCAuLi4KCgpDdXJyZW50bHkgUEcgaGFzIGFzc3VtZWQgdGltZV90J3MgYXJlIHBvc2l0aXZlLCBk
aWRuJ3QgaXQ/CgoKc3RhdGljIGludApwcVNvY2tldFBvbGwoaW50IHNvY2ssIGludCBmb3JSZWFk
LCBpbnQgZm9yV3JpdGUsIHRpbWVfdCBlbmRfdGltZSkKewouLi4KaWYgKGVuZF90aW1lID09ICgo
dGltZV90KSAtMSkpCnRpbWVvdXRfbXMgPSAtMTsKZWxzZQp7CnRpbWVfdG5vdyA9IHRpbWUoTlVM
TCk7CgoKaWYgKGVuZF90aW1lID4gbm93KQouLi4KfQoKCgoKPkFuZCB5b3UnZCBzdGlsbCBub3Qg
aGF2ZSBkZWFsdCB3aXRoIFBHQ09OTkVDVF9USU1FT1VUID4gMl4zMSwgd2hpY2ggYXJndWFibHkg
aXMgYW5vdGhlciAiYnVnIgo+Y2FzZSBoZXJlLgoKCkluIG15IHRlc3Qgd2hlbiBQR0NPTk5FQ1Rf
VElNRU9VVCA+IDJeMzEsIGF0b2koKSB3aWxsIGFsd2F5cyByZXR1cm4gMl4zMS4KCgppbnR0aW1l
b3V0ID0gYXRvaShjb25uLT5jb25uZWN0X3RpbWVvdXQpOwoKCgoKQmVzdCBSZWdhcmRzCkNoZW4g
SHVhanVu

On 10/21/2014 9:09 AM, chenhj wrote:
> Currently PG has assumed time_t's are positive, didn't it?
>

IIRC, time_t is an unsigned int.



--
john r pierce                                      37N 122W
somewhere on the middle of the left coast

John R Pierce <pierce@hogranch.com> writes:
> On 10/21/2014 9:09 AM, chenhj wrote:
>> Currently PG has assumed time_t's are positive, didn't it?

> IIRC, time_t is an unsigned int.

If it were, Unix programs couldn't deal with dates before 1970.

Originally time_t was usually a signed 32-bit int, allowing a range of
dates from about 1901 to 2038.  There were proposals at one time to "fix"
the Y2038 problem by redefining time_t as unsigned 32-bit, which would
kick the can down the road another 70 years at the price of breaking
pre-1970 dates.  But I think this idea has mostly fallen by the wayside
in favor of migrating to 64-bit-signed time_t.

On my Linux box, it looks like time_t is defined as "long int", which
means problem solved on 64-bit machines.  If anyone is still using
32-bit hardware in 2038, they're probably going to have to endure an
ABI break to widen time_t to int64.

            regards, tom lane

On 10/21/2014 10:49 AM, Tom Lane wrote:
> On my Linux box, it looks like time_t is defined as "long int", which
> means problem solved on 64-bit machines.  If anyone is still using
> 32-bit hardware in 2038, they're probably going to have to endure an
> ABI break to widen time_t to int64.

FWIW, on a 32bit CentOS 5 (kernel 2.6.18.el5) box I still have around,
it looks like time_t is __TIME_T_TYPE which is __SLONGWORD_TYPE which is
long int

(per grepping .h stuff in /usr/include...)

$ uname -a
Linux *** 2.6.18-398.el5 #1 SMP Tue Sep 16 20:51:48 EDT 2014 i686 i686
i386 GNU/Linux


--
john r pierce                                      37N 122W
somewhere on the middle of the left coast