On Thu, Aug 24, 2023 at 10:22:49AM +0900, Ian Lawrence Barwick wrote:
> Looking at the code, this is happening because
> "pgstat_fetch_stat_local_beentry()"
> expects to be passed the backend ID as an integer representing a 1-based index
> referring to "localBackendStatusTable", but "pg_stat_get_backend_subxact()"
> is presumably intended to take the actual BackendId , as per other
> "pg_stat_get_XXX()"
> functions.
Yes, this was changed in d7e39d7, but 10ea0f9 seems to have missed the
memo.
> Assuming I am not misunderstanding something here (always a
> possibility, apologies
> in advance if this is merely noise), what is actually needed is a function
> which
> accepts a BackendId (as per "pgstat_fetch_stat_beentry()"), but returns a
> LocalPgBackendStatus (as per "pgstat_fetch_stat_local_beentry()") like the
> attached, clumsily named "pgstat_fetch_stat_backend_local_beentry()".
I think you are right. The relevant information is only available in
LocalPgBackendStatus, but there's presently no helper function for
obtaining the "local" status with the BackendId.
> +LocalPgBackendStatus *
> +pgstat_fetch_stat_backend_local_beentry(BackendId beid)
> +{
> + LocalPgBackendStatus key;
> +
> + pgstat_read_current_status();
> +
> + /*
> + * Since the localBackendStatusTable is in order by backend_id, we can
> use
> + * bsearch() to search it efficiently.
> + */
> + key.backend_id = beid;
> +
> + return (LocalPgBackendStatus *) bsearch(&key, localBackendStatusTable,
> +
> localNumBackends,
> +
> sizeof(LocalPgBackendStatus),
> +
> cmp_lbestatus);
> +}
We could probably modify pgstat_fetch_stat_beentry() to use this new
function. I suspect we'll want to work on the naming, too. Maybe we could
name them pg_stat_fetch_local_beentry_by_index() and
pg_stat_fetch_local_beentry_by_backendid().
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
