Re: Options to control remote transactions’ access/deferrable modes in postgres_fdw
Etsuro Fujita <etsuro.fujita@gmail.com>
From: Etsuro Fujita <etsuro.fujita@gmail.com>
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>
Date: 2026-03-09T11:41:04Z
Lists: 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
Commits
-
postgres_fdw: Inherit the local transaction's access/deferrable modes.
- de28140ded8d 19 (unreleased) landed
- e5a3c9d9b5ce 18.0 landed
-
Revert "postgres_fdw: Inherit the local transaction's access/deferrable modes."
- 7d4667c6203d 18.0 cited