Re: Improve LWLock tranche name visibility across backends
| От | Nathan Bossart |
|---|---|
| Тема | Re: Improve LWLock tranche name visibility across backends |
| Дата | |
| Msg-id | aRIXtvkYn1mmyNG5@nathan обсуждение исходный текст |
| Ответ на | Re: Improve LWLock tranche name visibility across backends (Nathan Bossart <nathandbossart@gmail.com>) |
| Ответы |
Re: Improve LWLock tranche name visibility across backends
|
| Список | pgsql-hackers |
On Mon, Nov 10, 2025 at 10:26:17AM -0600, Nathan Bossart wrote: > On Mon, Nov 03, 2025 at 11:50:48AM -0600, Sami Imseih wrote: >>>> I am not sure we need to do anything about this. >>> >>> Or maybe we just avoid the tranche_id from leaking >>> in test_dsa_resowners() by making it a static variable >>> and checking if we have a valid tranche id before calling >>> LWLockNewTrancheId()? That is the proper pattern. >> >> Like the attached. > > It's probably a good idea to avoid tranche leaks, but IMHO there's room for > improvement in the DSM registry, too. IIUC the problem is that the DSM > segment is still being added to the registry and found by other backends > despite the initialization callback failing. My first instinct is that we > should keep track of whether the DSM segments/DSAs/dshash tables in the > registry have been fully initialized and to just ERROR in other backends > when attaching if they aren't. That shouldn't really happen in practice, > but it'd be good to avoid the strange errors, anyway. BTW if we really wanted to avoid leaking tranches in test_dsa, we'd need to store the ID in shared memory. Your patch helps in the case where a single backend is repeatedly calling test_dsa_resowners(), but other backends would still allocate their own tranche. I don't see a strong need to fix this on back-branches, given these functions run exactly once as part of a test, but fixing it on master seems worthwhile so that extension authors don't copy/paste this broken code. -- nathan
В списке pgsql-hackers по дате отправления: