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/
