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

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: 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-18 01:49:45
Message-ID: CAB7nPqT5P2yrfd9_M6_JKJpVWL0saUduK-RUXBVFNv4ZjPLw+g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 18, 2017 at 9:14 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> Superficially at least, it sounds like a good idea.

Indeed.

> We should only need a virtual xid when we're working with foreign
> tables since we don't do any local heap changes.
>
> How's it work with savepoints?

That's one thing to worry about.

At least to me, it feels like cheating to allow an INSERT query to
happen for a transaction which is read-only actually read-only because
XactReadOnly is set to true when the transaction starts. I am
wondering if we should extend BEGIN TRANSACTION with a sort of "WRITE
ONLY FOREIGN" mode, which allows read queries as well as write queries
for foreign tables, because we know that those will not generate WAL
locally. This way it would be possible to block as well INSERT queries
happening in a transaction which should be intrinsically read-only.

+ if (rte->relkind == 'f')
+ continue;
Better to use RELKIND_FOREIGN_TABLE here.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2017-10-18 02:45:52 A handful of typos in allpaths.c
Previous Message Amit Langote 2017-10-18 01:00:35 Re: [COMMITTERS] pgsql: Implement table partitioning.