Re: FDW for PostgreSQL
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Albe Laurenz <laurenz.albe@wien.gv.at>, Shigeru Hanada <shigeru.hanada@gmail.com>, Kohei KaiGai <kaigai@kaigai.gr.jp>, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2013-02-21T15:02:11Z
Lists: pgsql-hackers
On 2013-02-21 09:58:57 -0500, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > On 2013-02-21 14:23:35 +0000, Albe Laurenz wrote: > >> Tom Lane wrote: > >>> Another thing I was wondering about, but did not change, is that if we're > >>> having the remote transaction inherit the local transaction's isolation > >>> level, shouldn't it inherit the READ ONLY property as well? > > >> That seems to me like it would be the right thing to do. > > > I am not 100% convinced of that. There might be valid usecases where a > > standby executes queries on the primary that executes that do DML. And > > there would be no way out of it I think? > > How exactly would it do that via an FDW? Surely if the user tries to > execute INSERT/UPDATE/DELETE against a foreign table, the command would > get rejected in a read-only transaction, long before we even figure out > that the target is a foreign table? I was thinking of querying a remote table thats actually a view. Which might be using a function that does caching into a table or something. Not a completely unreasonable design. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services