| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Improve LWLock tranche name visibility across backends |
| Date: | 2025-08-19 20:26:41 |
| Message-ID: | 876523.1755635201@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
> On Tue, Aug 19, 2025 at 02:37:19PM -0400, Andres Freund wrote:
>> Sure, but we don't need to support a large number of tranches. Just make it,
>> idk, 128 entries long. Adding a dynamically allocated dsm to every server
>> seems like a waste - ever shared mapping makes fork / exit slower...
> The other issue is that there's presently no limit on the length of a
> tranche name registered via LWLockRegisterTranche(). Life would become
> much simpler if we're willing to put a limit on both that and the number of
> tranches, but thus far we've been trying to avoid it.
I can hardly imagine a reason why it wouldn't be okay to limit the
lengths of tranche names. But especially so if an unlimited length
causes practical problems.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2025-08-19 20:45:01 | Re: A few patches to clarify snapshot management |
| Previous Message | Peter Eisentraut | 2025-08-19 20:18:30 | Re: Generate GUC tables from .dat file |