From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Robins Tharakan <tharakan(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add pg_accept_connections_start_time() for better uptime calculation |
Date: | 2025-02-17 00:14:09 |
Message-ID: | Z7J_UZYfvtPiNMSy@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-02-17 00:24:24 | Re: BackgroundPsql swallowing errors on windows |
Previous Message | Andres Freund | 2025-02-17 00:03:39 | Re: BackgroundPsql swallowing errors on windows |