| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | Jingtang Zhang <mrdrivingduck(at)gmail(dot)com> |
| Cc: | pgsql-hackers mailing list <pgsql-hackers(at)lists(dot)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, hlinnaka(at)iki(dot)fi |
| Subject: | Re: Stale hash entries when reusing an auxiliary resource owner |
| Date: | 2026-11-02 11:28:41 |
| Message-ID: | F4DC045E-6199-481C-B359-CD921C15BD10@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Nov 2, 2026, at 18:13, Jingtang Zhang <mrdrivingduck(at)gmail(dot)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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeevan Chalke | 2026-11-02 11:34:26 | Re: PL/pgSQL: apply the too_many_rows extra check to EXECUTE ... INTO |
| Previous Message | Amit Kapila | 2026-11-02 11:16:55 | Re: Proposal: Conflict log history table for Logical Replication |