MIME-Version: 1.0
References: <E1uLe9X-000zsY-2g@gemulon.postgresql.org>
 <ed2296f1-1a6b-4932-b870-5bb18c2591ae@oss.nttdata.com>
 <aD0bg6Km5IigzUkC@paquier.xyz>
 <CAPmGK17Vf4fWt=+kCZ8V3JP7jO6iMrUze7TjOVtGzZwNbevnwg@mail.gmail.com>
 <CA+TgmoaVG_nH+nn5Qy_-P=d2dvtfnSPP8dQLUEv7+TLjrqhAtg@mail.gmail.com>
In-Reply-To: 
 <CA+TgmoaVG_nH+nn5Qy_-P=d2dvtfnSPP8dQLUEv7+TLjrqhAtg@mail.gmail.com>
From: Etsuro Fujita <etsuro.fujita@gmail.com>
Date: Thu, 5 Jun 2025 19:40:43 +0900
Message-ID: 
 <CAPmGK16yRFfMr4cKuL2ioqrhuLo0VrwrhwFre-x4cp2DzhPyqg@mail.gmail.com>
Subject: Re: pgsql: postgres_fdw: Inherit the local transaction's
 access/deferrable
To: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
 Fujii Masao <masao.fujii@oss.nttdata.com>,
	Etsuro Fujita <efujita@postgresql.org>, pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAPmGK16yRFfMr4cKuL2ioqrhuLo0VrwrhwFre-x4cp2DzhPyqg%40mail.gmail.com>
Precedence: bulk

On Thu, Jun 5, 2025 at 3:39=E2=80=AFAM Robert Haas <robertmhaas@gmail.com> =
wrote:
> On Tue, Jun 3, 2025 at 6:45=E2=80=AFAM Etsuro Fujita <etsuro.fujita@gmail=
.com> wrote:
> > 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=E2=80=99=
s a
> > good idea to add a note about that to the v18 release notes, as
> > proposed by Fujii-san.
>
> Sometimes, people can have different opinions about whether something
> is a bug fix or a behavior change. So far, I don't think you've
> convinced a single person either on the original thread or on this one
> that this is a bug fix, so I believe that, at present, the consensus
> is that this is a new feature. Although you may not agree with that
> consensus, and you may even be right, we all have to do what most
> people agree is right rather than what we ourselves prefer.

A consensus we reached on the original thread is that if the previous
behavior is considered problematic, we should fix it; otherwise, we
should not.  I proposed to fix it for the reason mentioned above, and
went ahead, as there were no objections about that.  But seeing the
comments on this thread, I have to agree that this is a feature rather
than a fix.

> For what it's worth, I agree with others that this is not just a bug
> fix: it's a behavior change that should be subject to the feature
> freeze. I personally think that it's probably a desirable behavior
> change, and that it's small enough that we could consider leaving it
> in v18 if that meets with general approval. We have had cases like
> this, where something feels too disruptive to back-patch, but is still
> on some level a fix or correction of behavior, in the past, and we
> have sometimes decided to handle those by allowing them to be added to
> the major release after the feature freeze deadline, but not
> back-patching them. So in my mind that is a possibility here.
>
> However, that would require a pretty unanimous agreement that this
> change is an improvement, and it appears to me that we don't have
> that. I read Fujii Masao's comments to indicate that he doesn't
> necessarily agree with the change and wants it reverted, and I read
> Michael Paquier's comments the same way. Unless I'm misunderstanding
> their position, this needs to be reverted.

Agreed.  I will revert this in a few days.  And I will re-propose it
as an improvement for v19.

Thanks for the discussion!

Best regards,
Etsuro Fujita