Re: GetNamedLWLockTranche crashes on Windows in normal backend
От | Sami Imseih |
---|---|
Тема | Re: GetNamedLWLockTranche crashes on Windows in normal backend |
Дата | |
Msg-id | CAA5RZ0u4BDp4ENjOyZ7NADz+jdQY-=PZFQNsf0jBt1Va4QzoAA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: GetNamedLWLockTranche crashes on Windows in normal backend (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: GetNamedLWLockTranche crashes on Windows in normal backend
|
Список | pgsql-hackers |
> On Fri, Aug 22, 2025 at 02:21:55PM -0500, Sami Imseih wrote: > > While working on [0], I observed that $SUBJECT. I encountered this issue > > while building test cases for [0], and in which GetNamedLWLockTranche is > > called outside of startup. > > > > [...] > > > > I repro'd this on a Windows machine, but one can also enable EXEC_BACKEND > > in pg_config_manual.h and call GetNamedLWLockTranche by a normal backend. > > > > I did this by injecting > > ``` > > GetNamedLWLockTranche("pg_stat_statements"); > > ``` > > inside pgss_ExecutorEnd > > If this fails, why doesn't the call in pgss_shmem_startup() also fail? Was > pg_stat_statements not loaded via shared_preload_libraries? because the array is valid in postmaster, but it's not for a normal backend, since it's not getting copied. Yes, pg_stat_statements was loaded via shared_preload_libraries. Nothing was done out of the ordinary. > And is the > failure a segfault or a "requested tranche is not registered" error? It's a segfault. -- Sami
В списке pgsql-hackers по дате отправления: