Stale hash entries when reusing an auxiliary resource owner
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t254514psql -h localhost -U postgresBuilt from patchset v1 (message #1), November 02, 2026 at 10:26 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t254514_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t254514_1 && git checkout t254514_1Patchset v1 (message #1) is on t254514_1
Hi,
While hacking on the code, I noticed a problem with auxiliary process
resource owners. Sorting and bulk release leave stale entries in the
owner’s hash table, but ReleaseAuxProcessResources() resets the flags to
allow reuse without clearing them.
On reuse, stale entries can be mistaken for resources acquired in the
current cycle and released again. They can also leave the table with no
empty slots, causing insertion to loop indefinitely while searching for
one.
The attached patch clears the entire hash table after resource release,
before allowing the auxiliary owner to be reused. This also removes
stale copies left beyond the sorted prefix.
I think this was introduced by b8bff07daa8. Any comments on this fix?
---
Regards,
Jingtang
On Nov 2, 2026, at 18:13, Jingtang Zhang <mrdrivingduck@gmail.com> wrote:
Hi,
While hacking on the code, I noticed a problem with auxiliary process
resource owners. Sorting and bulk release leave stale entries in the
owner’s hash table, but ReleaseAuxProcessResources() resets the flags to
allow reuse without clearing them.On reuse, stale entries can be mistaken for resources acquired in the
current cycle and released again. They can also leave the table with no
empty slots, causing insertion to loop indefinitely while searching for
one.The attached patch clears the entire hash table after resource release,
before allowing the auxiliary owner to be reused. This also removes
stale copies left beyond the sorted prefix.I think this was introduced by b8bff07daa8. Any comments on this fix?
---
Regards,
Jingtang
<v1-aux-resource-owner-reuse.patch>
Thanks for the patch.
The fix looks good to me. However, when I tried running the test with the fix reverted, the test hung indefinitely, which doesn't seem desirable. Ideally, the test should fail rather than hang when the fix is absent. It’s late here, I haven’t spent time debugging why the test hang.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/