Re: Is postgres ready for 2038?

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?

What I had in mind was more along the lines of making sure that
popular PG-on-Windows installers (EDB for instance) are not still
using 32-bit-time_t Perl.

BTW, just to clarify: AFAIK we *only* use the platform's time_t
for the result of time(2) and calculations involving relatively
small offsets from that, such as timeout expiration points.
All our stored data has been Y2038-safe since we got rid of the
abstime type.

Thus, I pretty much reject the OP's position that this is something
people really need to worry about years in advance. By the time
it breaks for real, everything else on the platform will be broken
too, unless the platform has done something about redefining time_t.

regards, tom lane