Re: Unexpected changes of CurrentResourceOwner and CurrentMemoryContext
Euler Taveira <euler@eulerto.com>
From: "Euler Taveira" <euler@eulerto.com>
To: Álvaro Herrera <alvherre@kurilemu.de>, "Antonin Houska" <ah@cybertec.at>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-09-11T20:38:23Z
Lists: pgsql-hackers
On Thu, Sep 11, 2025, at 3:05 PM, Álvaro Herrera wrote: > On 2025-Sep-03, Antonin Houska wrote: > >> When working on the REPACK command, we see an ERROR caused by unexpected >> change of CurrentResourceOwner [1]. I think the problem is that >> reorderbuffer.c does not restore the original value after calling >> RollbackAndReleaseCurrentSubTransaction(). The attached patch tries to handle >> the call like other callers throughout the tree do. > Interesting. I'm wondering that if this patch is applied we could remove the following code /* * Logical decoding could have clobbered CurrentResourceOwner during * transaction management, so restore the executor's value. (This is * a kluge, but it's not worth cleaning up right now.) */ CurrentResourceOwner = old_resowner; from pg_logical_slot_get_changes_guts and LogicalSlotAdvanceAndCheckSnapState functions too. IIUC the referred code is a band-aid that will be improved someday. > I have registered this as > https://commitfest.postgresql.org/patch/6051/ > > I've been wondering whether this should be backpatched. In principle > this is a bugfix, so it should, but I don't offhand recall any cases > where failure to set the current context/resowner in the other > reorderbuffer.c users causes a live bug, so ... maybe master only? I'm > wondering if it's possible where anybody _depends_ on the current > behavior, but I suppose that's quite unlikely. > I would say apply it to master only. If/when we have a bug report we can backpatch it. Per the crash description, I'm not sure we can create a reproducible test case with the current supported commands. Am I wrong? > It applies cleanly back to 14, so I would probably stop there in any > case. (A good thing also, because if we mess up 13 with it now and > don't notice until after the next minor is out, there won't be a chance > to unbreak it later.) > I would also refrain to apply scary fixes into an EOL branch. -- Euler Taveira EDB https://www.enterprisedb.com/
Commits
-
Avoid unexpected changes of CurrentResourceOwner and CurrentMemoryContext
- 7dcea51c2a4d 19 (unreleased) landed