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
- v2-0001-Add-support-for-pg_postmaster_open_time.patch (application/x-patch) patch v2-0001
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