Re: GUC thread-safety approaches
| От | Jelte Fennema-Nio |
|---|---|
| Тема | Re: GUC thread-safety approaches |
| Дата | |
| Msg-id | CAGECzQTuFaMcCPbQQQ9JDpkESkkHB==cvWVNzHR+vK6JLPwAFg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: GUC thread-safety approaches (Peter Eisentraut <peter@eisentraut.org>) |
| Ответы |
Re: GUC thread-safety approaches
|
| Список | pgsql-hackers |
On Tue, Nov 18, 2025, 11:26 Peter Eisentraut <peter@eisentraut.org> wrote:
The way I understand this, this would only work if
DefineCustomXXXVariable could only be called from a global context
(e.g., shared_preload_libraries). But AFAICT, you can define custom GUC
parameters per session (e.g., LOAD 'auto_explain'), and so each session
would have a different offset, and so the offset variable would itself
have to be session-local.
I think that a session-local LOAD is something we're going to lose with threading anyway. A shared library is only going to be loaded once for the cluster, not once per backend. And to be clear: I think that's totally fine. (i.e. the benefit of these session-local extensions seems to small for us to find and maintain some workaround for this)
So having a DefineCustomXXXVariable only be callable from a global context seems fine to me.
I quite like the idea of this global offset array btw.
В списке pgsql-hackers по дате отправления: