Re: Options to control remote transactions’ access/deferrable modes in postgres_fdw - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: Options to control remote transactions’ access/deferrable modes in postgres_fdw
Date
Msg-id CAPmGK1747FU1_q+z4xtHk2sGt8bUWyYo0G2Wst8R__ND_ybLfw@mail.gmail.com
Whole thread Raw
In response to Re: Options to control remote transactions’ access/deferrable modes in postgres_fdw  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: Options to control remote transactions’ access/deferrable modes in postgres_fdw
List pgsql-hackers
On Mon, Mar 9, 2026 at 12:47 PM 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%.  Thanks for the comments!

Best regards,
Etsuro Fujita



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: pg_stat_replication.*_lag sometimes shows NULL during active replication
Next
From: Akshay Joshi
Date:
Subject: Re: [PATCH] Add pg_get_database_ddl() function to reconstruct CREATE DATABASE statement