MIME-Version: 1.0
References: 
 <CAPmGK16n_hcUUWuOdmeUS+w4Q6dZvTEDHb=OP=5JBzo-M3QmpQ@mail.gmail.com>
 <CAExHW5vOH-=1KhaL8S4xVVzSozvrbmbBVg97p0obwEW3sD57Cw@mail.gmail.com>
 <3660951.1741016970@sss.pgh.pa.us>
 <CAPmGK14Btk0odkH6vwBhBGjCexmmWcM_D3DG0pJtObj8k_Unag@mail.gmail.com>
 <CAExHW5vVwZdvW1Dfy3oJXVDBffJUvAwhaCw3HCSC38B1ie_H1A@mail.gmail.com>
 <CAPmGK16pn+k0tLNR8NvZdtiADpnjZPYK-HuaxwOmzHzUgTE7_A@mail.gmail.com>
 <CAPmGK14Zn9NwKPPmBrUyN9ALBJa2nv75-LOVKNBgRN=ehYnKkw@mail.gmail.com>
 <CAPmGK150ucoQy96dUu6nu5iXBxyqrPrpqR2KMZN2CCSrMq0USw@mail.gmail.com>
 <CAPmGK15AQBXTgF_8EK=AY-Q6OLmhTuQSTWittLSVrw9Rvec25g@mail.gmail.com>
 <CAPmGK14fT9_hdC40s7MWZX+-k87AvyusG0qjd6zvngEgumdNgw@mail.gmail.com>
 <CAPmGK14RxMWYmNEHcjn04ZuvqxZrbasPT+zMNdd3T2V3R9Rz2A@mail.gmail.com>
 <CAPmGK14ZTHRGPprEhzEe2TJxaCcjNVeWw6tue_gqp=9DzqYnMA@mail.gmail.com>
 <CAHGQGwHjeZNppb4N7oG4vdPT1i2RY+=YRA=NUwhwYgpsjRyxfA@mail.gmail.com>
 <CAPmGK17-a8U=OdATsG5b2itLMbgEv3sOUP52NmTBGzS2TZjxjg@mail.gmail.com>
 <CAExHW5u5KCMvBhy8sbr69AGRxz489=ySqd0irgjF8myB+=b=hg@mail.gmail.com>
 <CAPmGK1747FU1_q+z4xtHk2sGt8bUWyYo0G2Wst8R__ND_ybLfw@mail.gmail.com>
In-Reply-To: 
 <CAPmGK1747FU1_q+z4xtHk2sGt8bUWyYo0G2Wst8R__ND_ybLfw@mail.gmail.com>
From: Etsuro Fujita <etsuro.fujita@gmail.com>
Date: Fri, 27 Mar 2026 20:41:29 +0900
Message-ID: 
 <CAPmGK17-kgpiWmHd52ogOLUx=F00xL43G_MUnApNeSgeTQaBjA@mail.gmail.com>
Subject: 
 =?UTF-8?Q?Re=3A_Options_to_control_remote_transactions=E2=80=99_access?=
	=?UTF-8?Q?=2Fdeferrable_modes_in_postgres=5Ffdw?=
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	PostgreSQL Hackers <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/CAPmGK17-kgpiWmHd52ogOLUx%3DF00xL43G_MUnApNeSgeTQaBjA%40mail.gmail.com>
Precedence: bulk

On Mon, Mar 9, 2026 at 8:41=E2=80=AFPM Etsuro Fujita <etsuro.fujita@gmail.c=
om> wrote:
> On Mon, Mar 9, 2026 at 12:47=E2=80=AFPM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> > If the primary doesn't allow modifying data in the foreign table in a
> > read-only transaction, a standby shouldn't do that either. The users
> > who are expecting a read-only transaction to protect against any
> > writes to the foreign data on primary will also expect so on the
> > standby. If users want to use standby's ability to modify foreign data
> > for the sake of load balancing, that's a reasonable ask. However, we
> > need to figure out whether it's common enough to support. That
> > information is not readily available. I doubt that it's a common
> > usecase. If this fix breaks such applications, we will come to know
> > its spread. And such applications can use dblink. Alternately we can
> > add the option which I and Tom didn't like [1]. But I feel we should
> > do that only if there are complaints. It's going to be painful to
> > those users who experience application breakage. To ease that pain we
> > should highlight this as a compatibility break change in the beta
> > release notes, giving users a chance to complain during beta cycle so
> > that we can fix it by GA.
> >
> > If others know that the current behaviour has a widespread
> > consumption, and they can provide backing data, adding the option
> > right away is better.
>
> +1; I agree with you 100%.

Barring objections, I'll commit the patch early next week.

Best regards,
Etsuro Fujita