Re: Function to track shmem reinit time

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Function to track shmem reinit time
Date: 2020-02-22 17:01:45
Message-ID: 26728.1582390905@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> writes:
> 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.

I'm still going to object to it, on the grounds that

(1) it's exposing an implementation detail that clients should not be
concerned with, and that we might change in future. The name isn't
even well chosen --- if the argument is that it's useful to monitor
server uptime, why isn't the name "pg_server_uptime"?

(2) if your server is crashing often enough that postmaster start
time isn't an adequate substitute, you have way worse problems than
whether you can measure it. I'd rather see us put effort into
fixing whatever the underlying problem is.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2020-02-22 17:43:20 Re: Function to track shmem reinit time
Previous Message Alexander Korotkov 2020-02-22 16:39:31 Re: Function to track shmem reinit time