Re: Is postgres ready for 2038?

Поиск
Список
Период
Сортировка
От Pavel Borisov
Тема Re: Is postgres ready for 2038?
Дата
Msg-id CALT9ZEGrHdzymFPrezRMmOpEHq6VWt3bSrTF9uB9rpCqiNqq1A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Is postgres ready for 2038?  (方徳輝 <javaeecoding@gmail.com>)
Список pgsql-hackers
Дерево обсуждения

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 по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: POC: Better infrastructure for automated testing of concurrency issues
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module