| From: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> |
|---|---|
| To: | 方徳輝 <javaeecoding(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <stark(at)mit(dot)edu>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Is postgres ready for 2038? |
| Date: | 2020-11-25 14:22:41 |
| Message-ID: | CALT9ZEGrHdzymFPrezRMmOpEHq6VWt3bSrTF9uB9rpCqiNqq1A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2020-11-25 14:38:57 | Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module |
| Previous Message | Alexander Korotkov | 2020-11-25 14:10:54 | POC: Better infrastructure for automated testing of concurrency issues |