public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Ashutosh Bapat <[email protected]>
Cc: Etsuro Fujita <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Options to control remote transactions’ access/deferrable modes in postgres_fdw
Date: Mon, 03 Mar 2025 10:49:30 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAExHW5vOH-=1KhaL8S4xVVzSozvrbmbBVg97p0obwEW3sD57Cw@mail.gmail.com>
References: <CAPmGK16n_hcUUWuOdmeUS+w4Q6dZvTEDHb=OP=5JBzo-M3QmpQ@mail.gmail.com>
	<CAExHW5vOH-=1KhaL8S4xVVzSozvrbmbBVg97p0obwEW3sD57Cw@mail.gmail.com>

Ashutosh Bapat <[email protected]> writes:
> On Sun, Mar 2, 2025 at 5:14 PM Etsuro Fujita <[email protected]> wrote:
>> To avoid that, I would like to propose a server option,
>> inherit_read_only, to open the remote transactions in read-only mode
>> if the local transaction is read-only.

> Why do we need a server option. Either we say that a local READ ONLY
> transaction causing modifications on the foreign server is problematic
> or it's expected. But what's the point in giving that choice to the
> user? If we deem the behaviour problematic it should be considered as
> a bug and we should fix it. Otherwise not fix it.

I tend to agree with Ashutosh's position here.  Reasoning about
issues like this is hard enough already.  Having to figure out an
application's behavior under more than one setting makes it harder.
You may argue that "then the application can choose the behavior it
likes, so there's no need to figure out both behaviors".  But for a
lot of bits of code, that's not the situation; rather, they have to
be prepared to work under both settings, because someone else is
in charge of what the setting is.  (I don't know if either of you
recall our disastrous attempt at server-side autocommit, back around
7.3.  The reason that got reverted was exactly that there was too
much code that had to be prepared to work under either setting,
and it was too hard to make that happen.  So now I look with great
suspicion at anything that complicates our transactional behavior.)

>> I would also like to propose a server option, inherit_deferrable, to
>> open the remote transactions in deferrable mode if the local
>> transaction is deferrable.

> The documentation about deferrable is quite confusing. It says "The
> DEFERRABLE transaction property has no effect unless the transaction
> is also SERIALIZABLE and READ ONLY." But it doesn't tell what's the
> effect of deferrable transaction. But probably we don't need a server
> option here as well.

Yeah, same with this: we should either change it or not.  Multiple
possible transactional behaviors don't do anyone any favors.

			regards, tom lane

view thread (20+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Options to control remote transactions’ access/deferrable modes in postgres_fdw
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox