Re: Prevent crash when calling pgstat functions with unregistered stats kind
От
Bertrand Drouvot
Тема
Re: Prevent crash when calling pgstat functions with unregistered stats kind
Дата
Msg-id
akXntNv2344hoc6L@bdtpg
Ответ на
Список
Дерево обсуждения
Prevent crash when calling pgstat functions with unregistered stats kind Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Prevent crash when calling pgstat functions with unregistered stats kind Ewan Young <kdbase.hack@gmail.com>
Re: Prevent crash when calling pgstat functions with unregistered stats kind Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Prevent crash when calling pgstat functions with unregistered stats kind Michael Paquier <michael@paquier.xyz>
Re: Prevent crash when calling pgstat functions with unregistered stats kind Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Prevent crash when calling pgstat functions with unregistered stats kind Michael Paquier <michael@paquier.xyz>
Re: Prevent crash when calling pgstat functions with unregistered stats kind Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Prevent crash when calling pgstat functions with unregistered stats kind Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Prevent crash when calling pgstat functions with unregistered stats kind Michael Paquier <michael@paquier.xyz>
Re: Prevent crash when calling pgstat functions with unregistered stats kind Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Hi, On Thu, Jul 02, 2026 at 01:10:18PM +0900, Michael Paquier wrote: > On Thu, Jul 02, 2026 at 04:06:01AM +0000, Bertrand Drouvot wrote: > > 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). > > Nope, this was a different thing, doable in a couple of steps: > - Load the library. > - Write custom stats. > - Stop the server, flush the stats. > - Edit the configuration, not loading the library. > - Restart the server, loading failed. > > The problem of this thread ought to be blocked at its source, in the > extension itself: let's not give free hands to an extension to do what > it should not be allowed to do. There is a similar defense in > test_custom_rmgrs, as one example. We should just map to that. Ok but what about extensions that don't call pgstat_register_kind() at all? Your point is that they would see the issue during the development of the extension? (If so, I think I could agree). Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления
От: Chao Li
Дата: