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: https://github.com/postgres/postgres/search?q=_USE_32BIT_TIME_T Is it a good idea to remove `_USE_32BIT_TIME_T` code and build with 64bit Perl might solve 2038 problem? Best regards, Fang On Thu, Nov 19, 2020 at 4:34 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Pavel Borisov <pashkin.e...@gmail.com> writes: > > чт, 19 нояб. 2020 г. в 09:29, Greg Stark <st...@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 >
