> There are no 32bit Windows version builds since Postgres 11, see:
>
> https://www.postgresql.org/download/windows/
>
> but Postgres 13 still has the same 2038 problems.
>
>
>
> As @Pavel Borisov hints , I can find `_USE_32BIT_TIME_T` code here:
>
>
Hi dear pgsql hackers
Thanks for replies.
There are no 32bit Windows version builds since Postgres 11, see:
https://www.postgresql.org/download/windows/
but Postgres 13 still has the same 2038 problems.
As @Pavel Borisov hints , I can find `_USE_32BIT_TIME_T` code here:
Pavel Borisov writes:
> чт, 19 нояб. 2020 г. в 09:29, Greg Stark :
>> 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
чт, 19 нояб. 2020 г. в 09:29, Greg Stark :
> On Wed, 18 Nov 2020 at 12:22, Tom Lane wrote:
> >
> > Andrew Dunstan 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
On Wed, 18 Nov 2020 at 12:22, Tom Lane wrote:
>
> Andrew Dunstan 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
Andrew Dunstan 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
On 11/18/20 9:44 AM, Tom Lane wrote:
> Pavel Borisov 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.
>
Yes, I agree.
ср, 18 нояб. 2020 г. в 18:44, Tom Lane :
> Pavel Borisov 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
Pavel Borisov 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
>
> 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.
>
How about just a mention in the future
On 11/17/20 11:04 AM, Tom Lane wrote:
> =?UTF-8?B?5pa55b6z6Lyd?= 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
=?UTF-8?B?5pa55b6z6Lyd?= 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".
Hello dear pgsql hackers
I think Postgres had fix 2038 problems since 8.4, when I read in
stackexchange:
https://dba.stackexchange.com/a/233084/102852
So I test on my PC by simply change system date to `2040-09-25`:
- Windows 10 Home edition
- CPU: AMD 64 bit
- Postgres version
13 matches
Mail list logo
