Re: Re: Is anything preventing us from allowing write to foreign tables from standby?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: Is anything preventing us from allowing write to foreign tables from standby?
Date: 2017-10-27 07:44:36
Message-ID: CA+TgmoZsO1bhFzAJB30cBYdOLE3sqiyYoOjEGiKqgov_=va5Mw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 26, 2017 at 11:14 AM, Ashutosh Bapat
<ashutosh(dot)bapat(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2017-10-27 08:04:28 Reading timeline from pg_control on replication slave
Previous Message Simon Riggs 2017-10-27 07:34:10 Re: WIP: BRIN bloom indexes