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

From 方徳輝
Subject Re: Is postgres ready for 2038?
Date
Msg-id CANCxQfYymfYPrDHHmsRB91QDEmoXsgcfXx73j652UtO=a3yyYQ@mail.gmail.com
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?
List pgsql-hackers

Hi dear pgsql hackers


Thanks for replies.

There are no 32bit Windows version builds since Postgres 11, see:

https://www.postgresql.org/download/windows/

but Postgres 13 still has the same  2038 problems.

 

As @Pavel Borisov hints , I can find `_USE_32BIT_TIME_T` code here:

https://github.com/postgres/postgres/search?q=_USE_32BIT_TIME_T


Is it a good idea to remove `_USE_32BIT_TIME_T` code and build with 64bit Perl 

might solve 2038 problem?


Best regards,

Fang 


On Thu, Nov 19, 2020 at 4:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Pavel Borisov <pashkin.elfe@gmail.com> writes:
> чт, 19 нояб. 2020 г. в 09:29, Greg Stark <stark@mit.edu>:
>> Wait, is configuring with a Perl that has 32-bit time_t driving the
>> rest of Postgres to use 32-bit timestamps? That seems like the tail
>> wagging the dog.
>> It seems like a sensible compromise would be to have Postgres's
>> configure default to 64-bit time_t and have a flag to choose 32-bit
>> time_t and then have a configure check that errors out if the time_t
>> in Perl doesn't match with a hint to either find a newer Perl
>> distribution or configure with the flag to choose 32-bit. Ie, don't
>> silently assume users want 32-bit time_t but leave them the option to
>> choose it explicitly.

>  _USE_32BIT_TIME_T is available only on 32-bit platforms so the proposed
> flag will not be able to force 32-bit time_t, only allow it. On 64-bit
> platforms, we simply do not have a choice.

> I suppose that some 10+ years later the number of users willing to compile
> on 32-bit with dinosaur-aged Perl distribution will be nearly zero. So I
> suppose just mention this would be a funny fact in the documentation.

Yeah.  I can't get excited about putting additional effort, and
user-visible complexity, into this issue.  The only way it could matter
to people building Postgres today is if you suppose that the executables
they are building today will still be in use in 2038.  That seems a bit
hard to credit.  Ten years from now, that'd be a legitimate worry ...
but it's really hard to believe that these toolchains will still be
in use then.

(I would not be too surprised if we've dropped support for 32-bit
builds altogether by 2030.  Certainly, any platform that still
has 32-bit time_t by then is going to be in a world of hurt.)

                        regards, tom lane

pgsql-hackers by date:

Previous
From: Alexey Kondratov
Date:
Subject: Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit
Next
From: Bernd Helmle
Date:
Subject: Re: A few new options for CHECKPOINT