Re: Add pg_accept_connections_start_time() for better uptime calculation

Robins Tharakan <tharakan@gmail.com>

From: Robins Tharakan <tharakan@gmail.com>
To: Fujii Masao <fujii@postgresql.org>, Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-03-06T12:55:18Z
Lists: pgsql-hackers

Attachments

Hi,

Thanks for taking a look at the patch, and for your feedback.

On Wed, 5 Mar 2025 at 03:22, Fujii Masao <masao.fujii@oss.nttdata.com>
wrote:

> On 2025/02/16 16:05, Robins Tharakan wrote:
> > This patch introduces a new function pg_accept_connections_start_time().
>

Shouldn't this function also handle the time when the postmaster
> starts accepting read-only connections? With the patch, it doesn’t
> seem to cover that case, and it looks like an unexpected timestamp
> is returned when run on a standby server. Maybe the function should
> return a record with two columns — one for when the postmaster
> starts accepting read-only connections and another for normal
> connections?
>


I am not sure if I understand the question. For a given (re)start, a
database user would either be looking for a read-only or a read-write
start time (based on whether the server is a standby or not). Are you
saying that for a given instance of start, a database user would be
interested in two timestamps (once when the database became
ready to accept read-only connections, and then quickly thereafter
also began accepting read-writes?) Even if possible, that feels
unnecessary - but I may be misunderstanding here.

But you bring up a good point around standbys. Attached is v2 of
the patch that returns a more accurate time on a standby (ie. it
captures the time just after emitting a message that it's ready for
read-only connections).

Also, while at it, I also implemented Michael's suggestion [1] for
a better name pg_postmaster_open_time() which is in line with
the existing pg_postmaster_start_time().

Also, updated the documentation to reflect the above, patch
passes `make check` and applies cleanly on HEAD as of
588acf6d0ec1 (6th Mar).

-
robins

Reference:
1. https://www.postgresql.org/message-id/Z7J_UZYfvtPiNMSy%40paquier.xyz