Postgres Pro
Downloads
Home   >   mailing lists

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

From Pavel Borisov
Subject Re: Is postgres ready for 2038?
Date
Msg-id CALT9ZEGrHdzymFPrezRMmOpEHq6VWt3bSrTF9uB9rpCqiNqq1A@mail.gmail.com
Whole thread Raw
In response to Re: Is postgres ready for 2038?  (方徳輝 <javaeecoding@gmail.com>)
List pgsql-hackers
Tree view

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?


As it was mentioned above `_USE_32BIT_TIME_T` is not default flag for msvc builds, but perl can set this on purpose (or on the reason it is very ancient). Postgres will not set `_USE_32BIT_TIME_T` itself and and by default compiles with 64bit time, which is correct. But it regards the perl's choice in case it is made on purpose. If you face the problem with PG compiled with non-2038 compatible time please first check your perl, this is the reason.

Regards, Pavel Borisov.

pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: POC: Better infrastructure for automated testing of concurrency issues
Next
From: Bharath Rupireddy
Date:
Subject: Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module