Re: Is postgres ready for 2038? - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Is postgres ready for 2038?
Date
Msg-id 38e7b79f-a92e-b795-02b4-c2cc868c5423@dunslane.net
Whole thread Raw
In response to Re: Is postgres ready for 2038?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Is postgres ready for 2038?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 11/18/20 9:44 AM, Tom Lane wrote:
> Pavel Borisov <pashkin.elfe@gmail.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.
>
>             


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
perl.


https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=drongo&dt=2020-11-16%2012%3A59%3A17&stg=make


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: pg_stat_statements and "IN" conditions
Next
From: Alexey Kondratov
Date:
Subject: Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit