Re: Is postgres ready for 2038?

чт, 19 нояб. 2020 г. в 09:29, Greg Stark <stark(at)mit(dot)edu>:

> On Wed, 18 Nov 2020 at 12:22, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > > On 11/18/20 9:44 AM, Tom Lane wrote:
> > >> Hmm. Digging around, I see that Mkvcbuild.pm intentionally absorbs
> > >> _USE_32BIT_TIME_T when building with a Perl that defines that.
> > >> I don't know what the state of play is in terms of Windows Perl
> > >> distributions getting off of that, but maybe we should press people
> > >> to not be using such Perl builds.
> >
> > > I think there's a good argument to ban it if we're doing a 64 bit build
> > > (and why would we do anything else?)
> >
> > I'm not really eager to ban it. If somebody is building with an old
> > Perl distribution, and doesn't particularly care that the installation
> > will break in 2038, why should we force them to care?
>
> 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.

--
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>