Re: Function to track shmem reinit time

On Sun, Dec 23, 2018 at 11:14 PM Alexander Korotkov
<a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> On Tue, Apr 10, 2018 at 8:58 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Tue, Apr 10, 2018 at 9:07 AM, David Steele <david(at)pgmasters(dot)net> wrote:
> > > On 3/29/18 9:40 AM, Tomas Vondra wrote:
> > >> On 03/28/2018 08:55 PM, David Steele wrote:
> > >>> I'm setting this entry to Waiting on Author, but based on the discussion
> > >>> I think it should be Returned with Feedback.
> > >>
> > >> Fine with me.
> > >
> > > This entry has been marked Returned with Feedback.
> >
> > I guess I'm in the minority here, but I don't see why it isn't useful
> > to have something like this. It's a lot easier for a monitoring
> > process to poll for this kind of thing than it is to monitor the logs.
> > Not that log monitoring isn't a good idea, but this is pretty
> > lightweight.
>
> +1,
>
> I think the issue this patch is addressing is that PostgreSQL now
> doesn't have true uptime function. We now recommend using
> pg_postmaster_start_time() for uptime calculation, but that isn't it.
> When backed crashes, shmen is reinitialized and PostgreSQL is
> restarted then uptime should be reset to zero, but
> pg_postmaster_start_time() is not about that.
>
> The major argument against this patch I got from the thread is that we
> shouldn't introduce new functions exposing information, which could be
> already fetched from logs. However, I think following this logic we
> should remove pg_postmaster_start_time() too.

I've revised the patchset.

0001-remove_dead_shmem_reinit_code-v1.patch
* -n option is removed from getopt() argument, initdb help and documentation
* some comments are slightly revised

0002-shmem_init_time_v1.patch
* detailed function description is added to the documentation

From my point of view criticism of this patch was addressed by
argument, that pg_shmem_init_time() allows to calculate the server
uptime [1]. This is very basic information, which is reasonable to
get without log files parsing. It's more than year since [1] is
unanswered. So, I'm going to push this if no objections.

Links
1. https://www.postgresql.org/message-id/CAPpHfds3_CgNgK4nfcOBo2BfPMFS7yrDXDCPKJSqdGrpqoLwoQ%40mail.gmail.com

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company