Postgres Pro
Downloads
Home   >   mailing lists

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

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

From
Tom Lane
Date:
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

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

From
Nathan Bossart
Date:
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

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

From
Max Johnson
Date:
Hi Nathan,

I think your patch looks good, no objections. I am happy to have contributed.

Thanks,
Max
From: Nathan Bossart <nathandbossart@gmail.com>
Sent: Wednesday, September 25, 2024 1:48 PM
To: Max Johnson <max.johnson@novatechautomation.com>
Cc: tgl@sss.pgh.pa.us <tgl@sss.pgh.pa.us>; 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.
 
On Wed, Sep 25, 2024 at 03:17:45PM +0000, Max Johnson wrote:
> I have amended my patch to reflect the changes that were discussed and
> have verified on my system that it works the same as before. I have also
> fixed a typo and changed the name of the patch to more accurately reflect
> what it does now. Please let me know if there is anything else you'd like
> me to do.

Thanks!  I went through all the other uses of MyStartTime and fixed those
as needed, too.  Please let me know what you think.

--
nathan

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

From
Max Johnson
Date:
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.

Thanks,

Max
From: Nathan Bossart <nathandbossart@gmail.com>
Sent: Thursday, September 26, 2024 9:38 PM
To: Max Johnson <max.johnson@novatechautomation.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>; tgl@sss.pgh.pa.us <tgl@sss.pgh.pa.us>
Subject: Re: pg_ctl/miscinit: print "MyStartTime" as a long long instead of long to avoid 2038 problem.
 
On Wed, Sep 25, 2024 at 08:04:59PM +0000, Max Johnson wrote:
> I think your patch looks good, no objections. I am happy to have contributed.

Great.  I've attached what I have staged for commit.

My first instinct was to not bother back-patching this since all
currently-supported versions will have been out of support for over 8 years
by the time this becomes a practical issue.  However, I wonder if it makes
sense to back-patch for the kinds of 32-bit embedded systems you cited
upthread.  I can imagine that such systems might need to work for a very
long time without any software updates, in which case it'd probably be a
good idea to make this fix available in the next minor release.  What do
you think?

--
nathan

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

From
Nathan Bossart
Date:
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

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

From
Nathan Bossart
Date:
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