On Mon Jun 1, 2026 at 5:41 AM UTC, Michael Paquier wrote: > On Thu, May 28, 2026 at 05:11:42PM +0000, Tristan Partin wrote: >> Can you share how someone might use this additional information? >> >> Not sure I understand why we would want to expose the existence of the >> callbacks to make assertions at the SQL level. I see that in >> pgstat_register_kind(), we have the following code: >> >> We could extend these invariant checks to make sure that the callbacks >> are only set when fixed_amount is true for instance. I am very much open >> to having my mind changed. > > There is currently no internal mechanism to make sure that the > built-in stats kinds have a consistent setup in terms of flags and > callbacks set, so for developers we could immediately complain when > generating patches that add new stats kinds. For custom stats kinds, > loaded libraries could have more cross-checks.
I think there is still some confusion on my end about this line of discussion. > Perhaps it is not worth bothering at the end, and I'd be fine to keep > the data published as minimal as you see fit. Still, fixed_amount, > write_to_file and accessed_across_databases feel like useful > additions. The additional columns are now added in v2. Note that I named write_to_file as written_to_file for the column name. I wonder if persisted would be a better name for the column and if persisted would be a better name for PgStat_KindInfo::write_to_file. > If we keep shared_size, it may make sense to set it to NULL if we > don't know about it? That's the case of the built-in fixed-sized > stats kinds. We set the value for custom fixed-sized stats kinds. I believe that I also captured this correctly in v2. -- Tristan Partin PostgreSQL Contributors Team AWS (https://aws.amazon.com)
