From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Max Johnson <max(dot)johnson(at)novatechautomation(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_ctl/miscinit: print "MyStartTime" as a long long instead of long to avoid 2038 problem. |
Date: | 2024-09-24 20:26:47 |
Message-ID: | ZvMghxsFyYM9e9kT@nathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 24, 2024 at 07:33:24PM +0000, Max Johnson wrote:
> I have found an instance of a time overflow with the start time that is
> written in "postmaster.pid". On a 32-bit Linux system, if the system date
> is past 01/19/2038, when you start Postgres with `pg_ctl start -D
> {datadir} ...`, the start time will have rolled back to approximately
> 1900. This is an instance of the "2038 problem". On my system, pg_ctl
> will not exit if the start time has overflowed.
Nice find. I think this has been the case since the start time was added
to the lock files [0].
> - snprintf(buffer, sizeof(buffer), "%d\n%s\n%ld\n%d\n%s\n",
> + snprintf(buffer, sizeof(buffer), "%d\n%s\n%lld\n%d\n%s\n",
> amPostmaster ? (int) my_pid : -((int) my_pid),
> DataDir,
> - (long) MyStartTime,
> + (long long) MyStartTime,
> PostPortNumber,
> socketDir);
I think we should use INT64_FORMAT here. That'll choose the right length
modifier for the platform. And I don't think we need to cast MyStartTime,
since it's a pg_time_t (which is just an int64).
[0] https://postgr.es/c/30aeda4
--
nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2024-09-24 20:30:25 | Re: AIO writes vs hint bits vs checksums |
Previous Message | Dave Cramer | 2024-09-24 20:01:30 | Re: [PATCH] Add native windows on arm64 support |