Re: Is postgres ready for 2038?

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.

--
greg