Hey Ashutosh, I tracked down a flake in 003_resize_failures (fails roughly 1 in 5 runs). Two assertions fail at lines 157 and 163:
got: 't' expected: 'f' log message "failed to expand buffer pool structures" absent It's a SIGHUP delivery race. The test calls pg_reload_conf() from one backend, then calls pg_resize_shared_buffers() from a different one ($resizer). When the signal hasn't reached $resizer yet, NBuffersGUC is still the old shrunk value. resize_shared_buffers_internal() sees currentNBuffers == targetNBuffers, prints "no need to resize," returns true, and the injection point never fires. Server log from a failing run: 06:07:17.885 [514631] SELECT pg_reload_conf() 06:07:17.885 postmaster: received SIGHUP, reloading configuration files 06:07:17.887 [514627] shared buffers are already at 18, no need to resize As per discussion, attached patch (0009) moves the ALTER SYSTEM + pg_reload_conf() before creating the $resizer backend. The new backend picks up the updated NBuffersGUC on connect. Injection point attachment and all assertions stay the same. 30/30 clean after the fix. Thanks, Palak
v20260817-0009-buffermgr-fix-SIGHUP-race-in-003_resize_failures.patch
Description: Binary data
