From: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, 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-03 10:45:34 |
Message-ID: | CAPmGK17Vf4fWt=+kCZ8V3JP7jO6iMrUze7TjOVtGzZwNbevnwg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
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. 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.
Thank you for the comments!
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2025-06-03 18:19:37 | pgsql: Fix a pg_dump scenario for platforms where SEEK_CUR != 1. |
Previous Message | Fujii Masao | 2025-06-03 01:04:15 | pgsql: Rename log_lock_failure GUC to log_lock_failures for consistency |
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2025-06-03 11:04:24 | Re: Proposal: Limitations of palloc inside checkpointer |
Previous Message | Xuneng Zhou | 2025-06-03 10:44:54 | Re: Add CHECK_FOR_INTERRUPTS in polling loop code path in XactLockTableWait |