Re: pgsql: postgres_fdw: Inherit the local transaction's access/deferrable

From: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Etsuro Fujita <efujita(at)postgresql(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: postgres_fdw: Inherit the local transaction's access/deferrable
Date: 2025-06-03 10:45:34
Message-ID: CAPmGK17Vf4fWt=+kCZ8V3JP7jO6iMrUze7TjOVtGzZwNbevnwg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Mon, Jun 2, 2025 at 12:33 PM Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Noah Misch 2025-06-03 18:19:37 pgsql: Fix a pg_dump scenario for platforms where SEEK_CUR != 1.
Previous Message Fujii Masao 2025-06-03 01:04:15 pgsql: Rename log_lock_failure GUC to log_lock_failures for consistency

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2025-06-03 11:04:24 Re: Proposal: Limitations of palloc inside checkpointer
Previous Message Xuneng Zhou 2025-06-03 10:44:54 Re: Add CHECK_FOR_INTERRUPTS in polling loop code path in XactLockTableWait