On Thu, Dec 11, 2025 at 9:29 AM Zhijie Hou (Fujitsu) <[email protected]> wrote: > On Thursday, December 11, 2025 3:09 PM Zhijie Hou (Fujitsu) > <[email protected]> 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
