Re: Options to control remote transactions’ access/deferrable modes in postgres_fdw

On Mon, Mar 9, 2026 at 8:41 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
> On Mon, Mar 9, 2026 at 12:47 PM Ashutosh Bapat
> <ashutosh(dot)bapat(dot)oss(at)gmail(dot)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