Thread: Is postgres ready for 2038?

=?UTF-8?B?5pa55b6z6Lyd?= <javaeecoding@gmail.com> writes:
> Is there any road map for 2038 problems in Postgres?

Postgres has no problem with post-2038 dates as long as you are using a
system with 64-bit time_t.  In other words, the road map is "get off
Windows, or press Microsoft to fix their problems".

            regards, tom lane

On 11/17/20 11:04 AM, Tom Lane wrote:
> =?UTF-8?B?5pa55b6z6Lyd?= <javaeecoding@gmail.com> writes:
>> Is there any road map for 2038 problems in Postgres?
> Postgres has no problem with post-2038 dates as long as you are using a
> system with 64-bit time_t.  In other words, the road map is "get off
> Windows, or press Microsoft to fix their problems".
>
>         


But it does: "time_t is, by default, equivalent to __time64_t." See

<https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/time-time32-time64?view=msvc-160>


Maybe we need to dig a little more to see what's going on here.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Pavel Borisov <pashkin.elfe@gmail.com> writes:
>> Maybe we need to dig a little more to see what's going on here.

> How about just a mention in the future documentation to never ever define
> _USE_32BIT_TIME_T when compiling PG under Windows? Should be enough, I
> suppose.

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.

            regards, tom lane

On 11/18/20 9:44 AM, Tom Lane wrote:
> Pavel Borisov <pashkin.elfe@gmail.com> writes:
>>> Maybe we need to dig a little more to see what's going on here.
>> How about just a mention in the future documentation to never ever define
>> _USE_32BIT_TIME_T when compiling PG under Windows? Should be enough, I
>> suppose.
> 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?)


Note that drongo appears not to need it - it's building against a 64 bit
perl.


https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=drongo&dt=2020-11-16%2012%3A59%3A17&stg=make


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Andrew Dunstan <andrew@dunslane.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

On Wed, 18 Nov 2020 at 12:22, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Andrew Dunstan <andrew@dunslane.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

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