Thread: Re: pg_ctl/miscinit: print "MyStartTime" as a long long instead of long to avoid 2038 problem.

Nathan Bossart <nathandbossart@gmail.com> writes:
> 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).

Agreed.  However, a quick grep finds half a dozen other places that
are casting MyStartTime to long.  We should fix them all.

Also note that if any of the other places are using translatable
format strings, INT64_FORMAT is problematic in that context, and
"long long" is a better answer for them.

(I've not dug in the history, but I rather imagine that this is all
a hangover from MyStartTime having once been plain "time_t".)

            regards, tom lane

On Tue, Sep 24, 2024 at 04:44:41PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> 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).
> 
> Agreed.  However, a quick grep finds half a dozen other places that
> are casting MyStartTime to long.  We should fix them all.

+1

> Also note that if any of the other places are using translatable
> format strings, INT64_FORMAT is problematic in that context, and
> "long long" is a better answer for them.

At a glance, I'm not seeing any translatable format strings that involve
MyStartTime.  But that is good to know...

-- 
nathan

On Fri, Sep 27, 2024 at 02:48:01PM +0000, Max Johnson wrote:
> I think that it would be a good idea to include these fixes in the next
> minor release. After working for a couple months on getting our embedded
> systems 2038 compliant, it has become very apparent that 2038 will be a
> substantial ordeal. Maximizing the number of systems that include this
> fix would make things a little easier when that time comes around.

Alright.  I was able to back-patch it to v12 without too much trouble,
fortunately.  I'll commit that soon unless anyone else has feedback.

-- 
nathan

On Fri, Sep 27, 2024 at 02:10:47PM -0500, Nathan Bossart wrote:
> Alright.  I was able to back-patch it to v12 without too much trouble,
> fortunately.  I'll commit that soon unless anyone else has feedback.

Committed, thanks!

I refrained from introducing INT64_HEX_FORMAT/UINT64_HEX_FORMAT in c.h
because I felt there was a nonzero chance of that causing problems with
third-party code on the back-branches.  We could probably add them for v18,
though.

-- 
nathan

On Mon, Oct 07, 2024 at 02:17:06PM -0500, Nathan Bossart wrote:
> On Mon, Oct 07, 2024 at 02:00:05PM -0500, Nathan Bossart wrote:
>> I refrained from introducing INT64_HEX_FORMAT/UINT64_HEX_FORMAT in c.h
>> because I felt there was a nonzero chance of that causing problems with
>> third-party code on the back-branches.  We could probably add them for v18,
>> though.
> 
> Like so...

If there are no concerns, I plan on committing this soon.

-- 
nathan

On Tue, Nov 19, 2024 at 05:00:43PM -0600, Nathan Bossart wrote:
> If there are no concerns, I plan on committing this soon.

Committed.

-- 
nathan