On Sun, Feb 16, 2025 at 11:47:46AM +0100, Laurenz Albe wrote: > I myself have never felt the need for such a function - but perhaps it > can be useful in these times of hosted database services, when accessing > the log file might be difficult.
Yeah. I'm not surprised by that. > I would probably have called the function pg_uptime(), yet maybe that > is too Unix-centric. pg_accept_connections_start_time() is very verbose. As it is about the postmaster being open to connections, perhaps pg_postmaster_open_time() for consistency with the existing start function? > Would it make sense to add that information to the output of > "pg_ctl status" as well? Perhaps as a new option, so that default output > format doesn't change. Hmm. Sounds to me that we could just have a SQL function that's able to parse postmaster.pid and returns its data in a format that makes its post-processing easier if we're OK to live with the fact that this could only be queried when the postmaster is able to accept connections, like a JSON object with dedicated key/value pairs. A separate function that only returns the open-for-connection time has benefits on its own because its execution can be granted to separate users, without knowing about the full contents of postmaster.pid. That last part should matter for cloud vendors. And this file only knows about MyStartTime. -- Michael
signature.asc
Description: PGP signature
