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

On Thu, Jun 5, 2025 at 3:39 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Jun 3, 2025 at 6:45 AM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)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’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