Hi, On Thu, Jul 02, 2026 at 12:43:43PM +0900, Michael Paquier wrote: > On Thu, Jul 02, 2026 at 03:27:18AM +0000, Bertrand Drouvot wrote: > > On Wed, Jul 01, 2026 at 04:20:39PM +0800, Ewan Young wrote: > >> One small thing: in pgstat_snapshot_fixed(), the existing > >> Assert(pgstat_is_kind_valid(kind)); becomes redundant after the new NULL > >> check. A non-NULL kind_info already implies the kind is valid (that's the > >> only way pgstat_get_kind_info() returns non-NULL), so the assert can never > >> fire. Might as well drop it and keep just the fixed_amount one. > > > > Yeah good catch, done in the attached. > > I am not convinced that it is worth bothering in the core code about > this class of failures; they are just not interesting, and impossible > to miss. > > It seems to me that this error is in the _PG_init() of the modules in > modules/test_custom_stats/: we should not bypass the > pgstat_register_kind() if not loading the library from > shared_preload_libraries, but let the call happen and fail.
I agree that the responsibility should primarily be in the extension. However, the issue is that the NULL dereference happens inside core code (pgstat_prep_pending_entry, etc.), and the resulting segfault(s) cause the postmaster to terminate all backends (not just the offending session). Given that one misconfigured extension can crash all connections on the server, a defensive check in core seems reasonable (kind of similar to 341e9a05e7b). Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
