Re: pg_ctl/miscinit: print "MyStartTime" as a long long instead of long to avoid 2038 problem.
| От | Max Johnson |
|---|---|
| Тема | Re: pg_ctl/miscinit: print "MyStartTime" as a long long instead of long to avoid 2038 problem. |
| Дата | |
| Msg-id | CO1PR07MB9052F0E98A65881F38775C7D8D6B2@CO1PR07MB9052.namprd07.prod.outlook.com обсуждение исходный текст |
| Ответ на | Re: pg_ctl/miscinit: print "MyStartTime" as a long long instead of long to avoid 2038 problem. (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: pg_ctl/miscinit: print "MyStartTime" as a long long instead of long to avoid 2038 problem.
|
| Список | pgsql-hackers |
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.
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
> 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
В списке pgsql-hackers по дате отправления: