Re: GetNamedLWLockTranche crashes on Windows in normal backend
От | Nathan Bossart |
---|---|
Тема | Re: GetNamedLWLockTranche crashes on Windows in normal backend |
Дата | |
Msg-id | aKyr_rVOtlolDcy-@nathan обсуждение исходный текст |
Ответ на | Re: GetNamedLWLockTranche crashes on Windows in normal backend (Sami Imseih <samimseih@gmail.com>) |
Ответы |
Re: GetNamedLWLockTranche crashes on Windows in normal backend
|
Список | pgsql-hackers |
On Mon, Aug 25, 2025 at 12:58:08PM -0500, Sami Imseih wrote: >> 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. Oh, I see what's happening. We are never calling GetNamedLWLockTranche() in backends because ShmemInitStruct() always sets *found. I'd argue that calling GetNamedLWLockTranche() outside of an "if (!found)" block in a shmem_startup_hook doesn't follow convention, but the docs have this note: shmem_startup_hook provides a convenient place for the initialization code, but it is not strictly required that all such code be placed in this hook. Like the inaccurate sentence immediately following this one [0], it was added by commit 964152c. IMHO we should adjust the documentation to match reality. [0] https://postgr.es/m/aJ9QIF3g2QQko9wq%40nathan -- nathan
В списке pgsql-hackers по дате отправления: