On Sat, Feb 22, 2020 at 10:31 PM Tom Lane <tgl@sss.pgh.pa.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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company