Hi Bharath, On Wed, 2 Sept 2026 at 16:23, Bharath Rupireddy <[email protected]> wrote: > > Hi, > > On Mon, Aug 17, 2026 at 6:44 AM Palak Chaturvedi > <[email protected]> wrote: > > > > I picked this up from the August CF and reproduced the CFBot "Test > > world" failure locally on postgres/master at 3d00537feb5 with 0001 > > and 0002 applied. I am writing this as a review rather than a v3, > > since you said 0002 is not meant for commit. > > Thanks for taking a look at it. > > > The wait needs two things: the worker is paused at the injection > > point, and it currently holds AccessShareLock on t. If neither is > > true yet, wake the point so the worker advances to the next > > check. Something like: > > I think passing the relation name as the injection point argument > (commit 0fd73cdffc1) makes the injection point fire only while the > worker is scanning the required table, so it can no longer pause on an > earlier relation and the race goes away. Does that work for you? >
Yes. I applied the three v3 patches to current master at 6168c65ddca and ran 002_autoprewarm_lock_yield ten times sequentially. All ten runs passed. I also checked the server log from the final run and did not find a crash or an unexpected error. The relation condition fixes the wrong-relation synchronization problem I reported. > I moved the LockHasWaiters() fix needed from > https://commitfest.postgresql.org/patch/6732/ here and made it the > 0001 patch. > Thanks. Making it 0001 resolves the dependency between the two changes. I found two other issues while reviewing v3. First, 0001 assumes that finding a LOCK in LockMethodLockHash means that this backend's fast-path lock has already been transferred and therefore has a PROCLOCK. I don't think that is guaranteed. For example, backend A can hold a weak relation lock through the fast path, while backend B acquires the same weak lock through the main lock table because its fast-path slots are full. In that case, the LOCK exists because of backend B, but backend A still has no PROCLOCK. If A calls LockHasWaiters(), 0001 finds the LOCK and then raises: ERROR: failed to re-find shared proclock object I think the lookup needs to find both the LOCK and MyProc's PROCLOCK while holding the partition lock. If either is absent, it should return false. The locallock pointers should only be assigned after both objects have been found. A test for this mixed fast-path and main-table state would also be useful. Second, the current CFBot run fails in the Linux 32-bit job. The 002_autoprewarm_lock_yield test sets: shared_buffers = '2GB' The server then fails during startup with: FATAL: invalid size -2147483648 for shared memory request for "Buffer Blocks" 0003 describes the test as manual/local, but it is registered in the Meson and Make test suites, so CFBot runs it. It either needs a portable configuration, an early skip on unsupported builds, or should remain unregistered if it is only intended for manual use. > I couldn't find a better way to make the test deterministic without a > large table, because the injection point can only be attached after > the restart when the worker is already scanning, so a long scan is > what gives the test enough time to attach before the worker finishes. > I'm open to thoughts here. > > Please find the attached v3 patches. > Thanks, Palak
