Re: Is postgres ready for 2038?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, 方徳輝 <javaeecoding(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Is postgres ready for 2038?
Date: 2020-11-18 17:16:27
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 11/18/20 9:44 AM, Tom Lane wrote:
>> Hmm. Digging around, I see that 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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2020-11-18 17:51:34 Re: PATCH: Batch/pipelining support for libpq
Previous Message Alexey Kondratov 2020-11-18 17:02:41 Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit