On Thu, Dec 11, 2025 at 9:29 AM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
> On Thursday, December 11, 2025 3:09 PM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote:
> > I reviewed that approach, and I think the main distinction lies in whether to
> > use a new LWLock to serialize the process or rely on an existing lock.
> > Introducing a new LWLock in back branches would alter the size of
> > MainLWLockArray and affect
> > NUM_INDIVIDUAL_LWLOCKS/LWTRANCHE_FIRST_USER_DEFINED.
> > Although this may not directly impact user applications since users typically
> > use standard APIs like RequestNamedLWLockTranche and
> > LWLockNewTrancheId to add private LWLocks, it still has a slight risk.
> > Additionally, using an existing lock could keep code similarity with the HEAD,
> > which can be helpful for future bug fixes and analysis.
>
> BTW, I searched the git history and can only find 2 old commits that adds lwlock
> On stable branches, but both of are fixing serious problems such as
> data corruption / loss issues.
I understand that that was done due to more serious reasons than ours.
As I get, it run smoothly. At least, I can't remember we have been
reported with any issues regarding to this change. Can we assume this
is kind of "tested" and add new LWLock to both master and back
branches? I think this would be good in terms of clarity and minimal
possible divergence of back branches.
------
Regards,
Alexander Korotkov
Supabase
