Re: Avoid core dump in pgstat_read_statsfile()
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-04-24T00:23:58Z
Lists: pgsql-hackers
On Wed, Apr 23, 2025 at 08:01:40AM +0000, Bertrand Drouvot wrote: > I think that a check on pgstat_get_kind_info() is missing for this scenario, the > patch adds it. Such a check already exists for PGSTAT_FILE_ENTRY_FIXED and > for stats entry identified by name on disk, but not for PGSTAT_FILE_ENTRY_HASH. It is, indeed. This can be reproduced with what's in core, just disable pgstat_register_inj_fixed() to bypass the check for fixed entries that would be read first if the module is removed from shared_preload_libraries in injection_points.c and we are good to go. I can see that you have copy-pasted the elog from the two other entry types. This is incomplete here because we are dealing with an entry in the dshash and we know its full key already: kind, database OID, object ID. And this can provide more information to help with the debugging. I have added this information, and applied the result. > The v18 existing checks mentioned above as well as the new check were missing > in pre-18 but I don't think it's worth a back-patch as the issue is unlikely to > occur without custom stats. Adding a v18 open item then. The check based on the kind ID should be enough, because this ensures that we'll have the PgStat_KindInfo to rely on. So stable branches are OK as they are. -- Michael
Commits
-
Add sanity check for dshash entries when reading pgstats file
- 923ae50cf559 18.0 landed