public inbox for [email protected]
help / color / mirror / Atom feedFrom: Etsuro Fujita <[email protected]>
To: Ashutosh Bapat <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Options to control remote transactions’ access/deferrable modes in postgres_fdw
Date: Mon, 9 Mar 2026 20:41:04 +0900
Message-ID: <CAPmGK1747FU1_q+z4xtHk2sGt8bUWyYo0G2Wst8R__ND_ybLfw@mail.gmail.com> (raw)
In-Reply-To: <CAExHW5u5KCMvBhy8sbr69AGRxz489=ySqd0irgjF8myB+=b=hg@mail.gmail.com>
References: <CAPmGK16n_hcUUWuOdmeUS+w4Q6dZvTEDHb=OP=5JBzo-M3QmpQ@mail.gmail.com>
<CAExHW5vOH-=1KhaL8S4xVVzSozvrbmbBVg97p0obwEW3sD57Cw@mail.gmail.com>
<[email protected]>
<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>
On Mon, Mar 9, 2026 at 12:47 PM Ashutosh Bapat
<[email protected]> 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%. Thanks for the comments!
Best regards,
Etsuro Fujita
view thread (20+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Re: Options to control remote transactions’ access/deferrable modes in postgres_fdw
In-Reply-To: <CAPmGK1747FU1_q+z4xtHk2sGt8bUWyYo0G2Wst8R__ND_ybLfw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox