Re: 32 bit libpq fail to connecting when set a very large "connect_timeout" value - Mailing list pgsql-bugs

From Tom Lane
Subject Re: 32 bit libpq fail to connecting when set a very large "connect_timeout" value
Date
Msg-id 7562.1413913742@sss.pgh.pa.us
Whole thread Raw
In response to Re: 32 bit libpq fail to connecting when set a very large "connect_timeout" value  (John R Pierce <pierce@hogranch.com>)
Responses Re: 32 bit libpq fail to connecting when set a very large "connect_timeout" value  (John R Pierce <pierce@hogranch.com>)
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: Peter Bailis
Date:
Subject: Re: BUG #11732: Non-serializable outcomes under serializable isolation
Next
From: Kevin Grittner
Date:
Subject: Re: BUG #11732: Non-serializable outcomes under serializable isolation