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

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Options to control remote transactions’ access/deferrable modes in postgres_fdw
Date: 2026-03-05 03:10:50
Message-ID: CAHGQGwHjeZNppb4N7oG4vdPT1i2RY+=YRA=NUwhwYgpsjRyxfA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 5, 2026 at 8:52 AM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
>
> On Wed, Feb 25, 2026 at 7:22 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
> > This was reverted in commit 7d4667c62. I'd like to re-propose it for
> > v19, as mentioned in [1]. Attached is a new patch, in which I added
> > to the documentation a note about login triggers executed on the
> > remote side, as discussed in [1]. Other than that, no changes. I've
> > added this to the upcoming CF.
>
> Here is an updated version of the patch. Changes are:
>
> * On second thought, I think the name of the variable
> top_read_only_level added to connection.c by the patch is a bit long,
> so I renamed it to top_read_only. Does that make sense? Other than
> that, no code changes.
> * I also added/modified some comments.
>
> Comments welcome!

I haven't yet realized the benefit from this change since I haven't
encountered issues caused by the current behavior (i.e., a remote transaction
starting in read-write mode while the corresponding local transaction on
the standby is read-only).

On the other hand, this change would force any remote transaction initiated by
a standby transaction to start in read-only mode, completely preventing it from
modifying data. Because transactions on a standby always start as read-only,
the remote transaction would also always be read-only under this proposal,
with no way to make it read-write.

I'm concerned that this could break certain use cases without providing
a clear benefit.

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2026-03-05 03:12:04 Re: UPDATE run check constraints for affected columns only
Previous Message Zhijie Hou (Fujitsu) 2026-03-05 02:46:00 RE: [PATCH] Support automatic sequence replication