Re: [HACKERS] Re: Is anything preventing us from allowing write toforeign tables from standby?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Re: Is anything preventing us from allowing write toforeign tables from standby?
Дата
Msg-id CA+TgmoZsO1bhFzAJB30cBYdOLE3sqiyYoOjEGiKqgov_=va5Mw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Re: Is anything preventing us from allowing write toforeign tables from standby?  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Ответы Re: [HACKERS] Re: Is anything preventing us from allowing write toforeign tables from standby?  (Michael Paquier <michael.paquier@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: [HACKERS] WIP: BRIN bloom indexes
Следующее
От: Andrey Borodin
Дата:
Сообщение: [HACKERS] Reading timeline from pg_control on replication slave