Re: [HACKERS] Re: Is anything preventing us from allowing write toforeign tables from standby? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Re: Is anything preventing us from allowing write toforeign tables from standby?
Date
Msg-id CA+TgmoZsO1bhFzAJB30cBYdOLE3sqiyYoOjEGiKqgov_=va5Mw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Re: Is anything preventing us from allowing write toforeign tables from standby?  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: [HACKERS] Re: Is anything preventing us from allowing write toforeign tables from standby?
List pgsql-hackers
On Thu, Oct 26, 2017 at 11:14 AM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
> In a nearby thread, we are discussing about atomic commit of
> transactions involving foreign transactions. For maintaining
> consistency, atomicity of transactions writing to foreign server, we
> will need to create local transactions. Will that be possible on
> standby? Obviously, we could add a restriction that no consistency and
> atomic commit is guaranteed when foreign servers are written from a
> standby. I am not sure how easy would be to impose such a restriction
> and whether such a restriction would be practical.

Yeah, that feature definitely can't work on a standby.  But we could
probably allow writes when that feature is not in use.  One thing that
bothers me about Alexander's patch is that there wouldn't be any way
to distinguish between those two cases.  Maybe we need a callback to
ask the FDW "given the configured options, could you work on a
standby?"

However, as Michael also points out, it's arguably wrong to allow a
nominally read-only transaction to write data regardless of whether it
works.  In the case of a standby it could be argued that your
transaction is only read-only because you had no other choice, but
nonetheless that's how it is marked.  I have a feeling that if we
extend the definition of "read only" to mean "sometimes allow writes",
we may regret it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [HACKERS] WIP: BRIN bloom indexes
Next
From: Andrey Borodin
Date:
Subject: [HACKERS] Reading timeline from pg_control on replication slave