Re: Is postgres ready for 2038?

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

On 11/18/20 9:44 AM, Tom Lane wrote:
> 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 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.

I think there's a good argument to ban it if we're doing a 64 bit build
(and why would we do anything else?)

Note that drongo appears not to need it - it's building against a 64 bit



Andrew Dunstan

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alexey Kondratov 2020-11-18 17:02:41 Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit
Previous Message Dmitry Dolgov 2020-11-18 16:04:32 Re: pg_stat_statements and "IN" conditions