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.1 64-bit
- Postgres version 10.14 64-bit
Both Postgres edition seems basically work:
- Postgres can start the process, and connect with psql/pgAdmin successfully. (but not show as “started” in services.msc)
- Table with the Timestamp column, test with basic CRUD sql is work.
But there are many strange logs, like:
cat postgresql-2040-09-25_123738.log
> 1904-08-20 06:09:23.083 JST [7520] LOG: stats_timestamp 2000-01-01 09:00:00+09 is later than collector's time 1904-08-20 06:09:23.083102+09 for database 0
> 1904-08-20 06:10:23.226 JST [13904] LOG: stats collector's time 2000-01-01 09:00:00+09 is later than backend local time 1904-08-20 06:10:23.22678+09
> 1904-08-20 06:10:23.227 JST [7520] LOG: stats_timestamp 2000-01-01 09:00:00+09 is later than collector's time 1904-08-20 06:10:23.227854+09 for database 12938
Note that log file name is OK, but logs content mix many time stamps (e.g 1904-08-20, 2000-01-01).
And I also found someone says in
https://www.postgresql-archive.org/Year-2038-Bug-td1990821.html
> PostgreSQL 8.4 uses 64bit data type for time. But if you use system timezone
> then you can get in trouble if system does not support 64bit zic files.
But IMO output content in logs is not OS problems, it should be Postgres’s 2038 bug.
As our products has 15 years support period, we need to think about 2038 seriously from now,
Is there any road map for 2038 problems in Postgres?
Best regards,
Fang
