On Mon, Nov 20, 2023 at 5:27 PM Jeff Davis <pg...@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
