Re: pgsql: postgres_fdw: Inherit the local transaction's access/deferrable - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: pgsql: postgres_fdw: Inherit the local transaction's access/deferrable
Date
Msg-id CAPmGK17Vf4fWt=+kCZ8V3JP7jO6iMrUze7TjOVtGzZwNbevnwg@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: postgres_fdw: Inherit the local transaction's access/deferrable  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Mon, Jun 2, 2025 at 12:33 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Mon, Jun 02, 2025 at 12:03:50PM +0900, Fujii Masao wrote:
> > I'm not sure this change should be considered a bug fix,
> > since the current behavior of postgres_fdw with a local read-only
> > transaction isn't clearly documented. Some users might see this
> > as a behavioral change rather than a fix. Anyway if we go with it,
> > shouldn't we document the change in the v18 release notes?
>
> After going through the thread and the commit, I have to admit that I
> was surprised to see this applied on HEAD now that we are in feature
> freeze.  This is a behavior change.  Perhaps this could be done once
> v19 happens, still it's rather unclear if the new behavior is better
> than the previous one.

No, this is a fix, not a feature, as discussed in the thread; as
mentioned in the commit message, the previous version of postgres_fdw
could cause surprising behaviors that would never happen in normal
cases where a read-only and/or deferrable transaction only
accesses/modifies data on the local server, so this commit fixes those
behaviors.  But yes, it makes a behavior change, so I think it’s a
good idea to add a note about that to the v18 release notes, as
proposed by Fujii-san.

Thank you for the comments!

Best regards,
Etsuro Fujita



pgsql-hackers by date:

Previous
From: Xuneng Zhou
Date:
Subject: Re: Add CHECK_FOR_INTERRUPTS in polling loop code path in XactLockTableWait
Next
From: Alexander Korotkov
Date:
Subject: Re: Proposal: Limitations of palloc inside checkpointer