Re: Is postgres ready for 2038?

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(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> writes:
> > чт, 19 нояб. 2020 г. в 09:29, Greg Stark <stark(at)mit(dot)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
>