public inbox for [email protected]  

help / color / mirror / Atom feed

From: Fujii Masao <[email protected]>
To: Etsuro Fujita <[email protected]>
To: Michael Paquier <[email protected]>
Cc: Etsuro Fujita <[email protected]>
Cc: [email protected]
Subject: Re: pgsql: postgres_fdw: Inherit the local transaction's access/deferrable
Date: Wed, 4 Jun 2025 13:14:44 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAPmGK17Vf4fWt=+kCZ8V3JP7jO6iMrUze7TjOVtGzZwNbevnwg@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<CAPmGK17Vf4fWt=+kCZ8V3JP7jO6iMrUze7TjOVtGzZwNbevnwg@mail.gmail.com>



On 2025/06/03 19:45, Etsuro Fujita wrote:
> On Mon, Jun 2, 2025 at 12:33 PM Michael Paquier <[email protected]> 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.

I agree this could be considered a fix if the new behavior has been
clearly explained in the documentation from before or based on
standards like SQL/MED. But if that's not the case, it seems more
like a behavior change. In that case, I think it should wait for v19
and be applied only after reaching consensus. Some systems might
rely on the previous behavior.

By the way, if a read-only transaction on the local server is meant
to block all write operations on the remote server, this patch alone
might not be sufficient, for example, that read-only transaction can
invoke a login trigger on the remote server and it could still
perform writes.

Regards,

-- 
Fujii Masao
NTT DATA Japan Corporation

view thread (12+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: pgsql: postgres_fdw: Inherit the local transaction's access/deferrable
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox