Date: Tue, 24 Sep 2024 15:26:47 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Max Johnson <max.johnson@novatechautomation.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: pg_ctl/miscinit: print "MyStartTime" as a long long instead of
 long to avoid 2038 problem.
Message-ID: <ZvMghxsFyYM9e9kT@nathan>
References: <CO1PR07MB905262E8AC270FAAACED66008D682@CO1PR07MB9052.namprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CO1PR07MB905262E8AC270FAAACED66008D682@CO1PR07MB9052.namprd07.prod.outlook.com>
Archived-At: <https://www.postgresql.org/message-id/ZvMghxsFyYM9e9kT%40nathan>
Precedence: bulk

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