Skip site navigation (1) Skip section navigation (2)

Re: pgsql_fdw, FDW for PostgreSQL server

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Shigeru Hanada *EXTERN*" <shigeru(dot)hanada(at)gmail(dot)com>, "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>
Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com>, "Kohei KaiGai" <kaigai(at)kaigai(dot)gr(dot)jp>, "Etsuro Fujita" <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Martijn van Oosterhout" <kleptog(at)svana(dot)org>
Subject: Re: pgsql_fdw, FDW for PostgreSQL server
Date: 2012-02-20 14:57:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> wrote:
> If your query involves foreign scans on two foreign tables on the
> same foreign server, these should always see the same snapshot,
> because that's how it works with two scans in one query on local
> tables.
That makes sense.
> So I think it should be REPEATABLE READ in all cases -
> SERIALIZABLE is not necessary as long as all you do is read.
That depends on whether you only want to see states of the database
which are consistent with later states of the database and any
invariants enforced by triggers or other software.  See this example
of how a read-only transaction can see a bogus state at REPEATABLE
READ or less strict transaction isolation:
Perhaps if the transaction using the pgsql_fdw is running at the
SERIALIZABLE transaction isolation level, it should run the queries
at the that level, otherwise at REPEATABLE READ.

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2012-02-20 15:22:50
Subject: Re: Incorrect behaviour when using a GiST index on points
Previous:From: Yeb HavingaDate: 2012-02-20 14:35:13
Subject: Re: [v9.2] Add GUC sepgsql.client_label

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group