From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | 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-04 04:14:44 |
Message-ID: | b269f7ad-90a7-4217-a58e-038899148718@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On 2025/06/03 19:45, Etsuro Fujita wrote:
> 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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2025-06-04 09:42:47 | pgsql: Don't strip $libdir from LOAD command |
Previous Message | Michael Paquier | 2025-06-04 00:02:06 | pgsql: psql: Abort connection when using \syncpipeline after COPY TO/FR |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-06-04 04:26:10 | Re: Improve explicit cursor handling in pg_stat_statements |
Previous Message | Thomas Munro | 2025-06-04 04:03:27 | Custom Glibc collation version strings under LOCPATH |