On Thu, Mar 5, 2026 at 8:52 AM Etsuro Fujita <[email protected]> wrote: > > On Wed, Feb 25, 2026 at 7:22 PM Etsuro Fujita <[email protected]> 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
