From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Sami Imseih <samimseih(at)gmail(dot)com> |
Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Improve LWLock tranche name visibility across backends |
Date: | 2025-07-11 21:58:30 |
Message-ID: | aHGJBt37dg37f1bE@nathan |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 11, 2025 at 04:32:13PM -0500, Sami Imseih wrote:
> Now, what I think will be a good API is to provide an alternative to
> LWLockRegisterTranche,
> which now takes in both a tranche ID and tranche_name. The new API I propose is
> LWLockRegisterTrancheWaitEventCustom which takes only a tranche_name
> and internally
> calls WaitEventCustomNew to add a new wait_event_info to the hash
> table. The wait_event_info
> is made up of classId = PG_WAIT_LWLOCK and LWLockNewTrancheId().
>
> I prefer we implement a new API for this to make it explicit that this
> API will both register
> a tranche and create a custom wait event. I do not think we should get
> rid of LWLockRegisterTranche
> because it is used by CreateLWLocks during startup and I don't see a
> reason to change that.
> See the attached v1.
Hm. I was thinking we could have LWLockNewTrancheId() take care of
registering the name. The CreateLWLocks() case strikes me as a special
path. IMHO LWLockRegisterTranche() should go away.
> Is there a concern with a custom wait event to be created implicitly
> via the GetNamed* APIs?
I'm not sure I see any particular advantage to using custom wait events
versus a dedicated LWLock tranche name table. If anything, the limits on
the number of tranches and the lengths of the names gives me pause.
--
nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Melanie Plageman | 2025-07-11 22:19:15 | Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) |
Previous Message | Aleksander Alekseev | 2025-07-11 21:32:31 | Re: XLogCtl->ckptFullXid is unused |