Re: Is postgres ready for 2038?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, 方徳輝 <javaeecoding(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Is postgres ready for 2038?
Date: 2020-11-18 14:44:46
Message-ID: 985310.1605710686@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> writes:
>> Maybe we need to dig a little more to see what's going on here.

> How about just a mention in the future documentation to never ever define
> _USE_32BIT_TIME_T when compiling PG under Windows? Should be enough, I
> suppose.

Hmm. Digging around, I see that Mkvcbuild.pm intentionally absorbs
_USE_32BIT_TIME_T when building with a Perl that defines that.
I don't know what the state of play is in terms of Windows Perl
distributions getting off of that, but maybe we should press people
to not be using such Perl builds.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2020-11-18 14:46:30 Re: proposal: possibility to read dumped table's name from file
Previous Message Bharath Rupireddy 2020-11-18 13:39:48 Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit