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

  1. Avoid unexpected changes of CurrentResourceOwner and CurrentMemoryContext