On Mon, Nov 20, 2023 at 5:27 PM Jeff Davis <pgsql@j-davis.com> wrote:
> Of course I welcome others to profile and see what they can do. There's
> a setjmp() call, and a couple allocations, and maybe some other stuff
> to look at. There are also higher-level ideas, like avoiding calling
> into guc.c in some cases, but that starts to get tricky as you pointed
> out:
>
> https://www.postgresql.org/message-id/CA%2BTgmoa8uKQgak5wH0%3D7sL-ukqbwnCPMXA2ZW7Ccdt7tdNGkzg%40mail.gmail.com
>
> It seems others are also interested in this problem, so I can put some
> more effort in after this round of patches goes in. I don't have a
> specific target other than "low enough overhead that we can reasonably
> recommend it as a best practice in multi-user environments".
The two things that jump out at me are the setjmp() and the
hash_search() call inside find_option(). As to the first, could we
remove the setjmp() and instead have abort-time processing know
something about this? For example, imagine we just push something onto
a stack like we do for ErrorContextCallback, do whatever, and then pop
it off. But if an error is thrown then the abort path knows to look at
that variable and do whatever. As to the second, could we somehow come
up with an API for guc.c where you can ask for an opaque handle that
will later allow you to do a fast-SET of a GUC? The opaque handle
would basically be the hashtable entry, perhaps with some kind of
wrapping or decoration. Then fmgr_security_definer() could obtain the
opaque handles and cache them in fn_extra.
(I'm just spitballing here.)
--
Robert Haas
EDB: http://www.enterprisedb.com