Re: Function to track shmem reinit time

On 2/24/20 10:57 PM, Robert Haas wrote:
> On Sat, Feb 22, 2020 at 10:31 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.
>
> I don't accept the first argument, because I think the chances that
> we'll change our basic approach to this problem are indistinguishable
> from zero. A few years back, you criticized some idea of mine as
> tantamount to rm -rf src/backend/optimizer, which you were not ready
> to endorse. That proposal was surely vastly less ambitious than some
> proposal which would remove the idea of shared memory reinitialization
> after an unsafe backend exit.
>
> I don't accept the second argument either, because it's a false
> dichotomy. Adding this function won't reduce the amount of energy that
> gets spent fixing crashes. There are always more crashes.
>
> I realize that several other people voted against this proposal so I
> don't think it's OK to commit a patch in this area unless some more
> positive votes turn up, but I'm still +1 on the idea. Granted, we
> don't want an infinite amount of clutter in the system catalogs, but I
> have a hard time believing that this proposed function would get any
> less use than the hyperbolic trig functions.

Marking this Returned with Feedback again since we are still at an impasse.

Regards,
--
-David
david(at)pgmasters(dot)net