| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Cc: | Ewan Young <kdbase(dot)hack(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Prevent crash when calling pgstat functions with unregistered stats kind |
| Date: | 2026-07-02 04:10:18 |
| Message-ID: | akXkqov6wLbKwpAd@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Haibo Yan | 2026-07-02 04:14:42 | Re: implement CAST(expr AS type FORMAT 'template') |
| Previous Message | David G. Johnston | 2026-07-02 04:08:13 | Re: implement CAST(expr AS type FORMAT 'template') |