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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: John R Pierce <pierce(at)hogranch(dot)com>
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 17:49:02
Message-ID: 7562.1413913742@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

John R Pierce <pierce(at)hogranch(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Kevin Grittner 2014-10-21 17:55:24 Re: BUG #11732: Non-serializable outcomes under serializable isolation
Previous Message Peter Bailis 2014-10-21 17:44:32 Re: BUG #11732: Non-serializable outcomes under serializable isolation