Re: Add pg_stat_kind_info system view - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Add pg_stat_kind_info system view
Date
Msg-id anBbl-zLV8SyjZ6i@paquier.xyz
Whole thread
In response to Re: Add pg_stat_kind_info system view  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
List pgsql-hackers
On Thu, Jul 30, 2026 at 08:18:21AM +0900, Michael Paquier wrote:
> In terms of this thread, more thought is a synonym of making sure that
> your proposal [2] is good enough for the purpose to be able to monitor
> the pgstats activity.  I'll try to look double-check this part
> separately; this naturally adds more value to the other proposal.

Just adding a note about that, while I don't forget about it
(apologies for the short digression..).

pgstat_dsa_init_size() currently documents the following thing:
/*
 * The size of the shared memory allocation for stats stored in the shared
 * stats hash table. This allocation will be done as part of the main shared
 * memory, rather than dynamic shared memory, allowing it to be initialized in
 * postmaster.
 */

Switching pgstats to use the DSM registry would imply a
dsa_create_ext(), that cannot happen in the postmaster (assert in
dsm.c), hence a DSM registry call in pgstat_initialize().  I think
that this initial idea may lack robustness, because we would delay the
pgstats initialization to happen later, at the first BaseInit() rather
than have the postmaster do the basics.  I haven't looked at how this
idea would bundle with the single user mode, but I'd feel that pgstats
may break also in this case.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: A new C function `get_partition_root`.
Next
From: Andrey Borodin
Date:
Subject: Re: walsummarizer can get stuck when switching timelines