Re: pgsql: postgres_fdw: Inherit the local transaction's access/deferrable
От | Fujii Masao |
---|---|
Тема | Re: pgsql: postgres_fdw: Inherit the local transaction's access/deferrable |
Дата | |
Msg-id | b269f7ad-90a7-4217-a58e-038899148718@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: pgsql: postgres_fdw: Inherit the local transaction's access/deferrable (Michael Paquier <michael@paquier.xyz>) |
Список | pgsql-hackers |
On 2025/06/03 19:45, Etsuro Fujita wrote: > On Mon, Jun 2, 2025 at 12:33 PM Michael Paquier <michael@paquier.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
В списке pgsql-hackers по дате отправления: