On Sat, Feb 22, 2020 at 10:31 PM Tom Lane <t...@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
