Re: FDW for PostgreSQL

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Shigeru Hanada <shigeru(dot)hanada(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>
Subject: Re: FDW for PostgreSQL
Date: 2013-03-28 12:38:12
Message-ID: 20130328123811.GR4361@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom, all,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) 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?

Apologies for bringing this up pretty late, but wrt writable FDW
transaction levels, I was *really* hoping that we'd be able to implement
autonomous transactions on top of writeable FDWs. It looks like there's
no way to do this using the postgres_fdw due to it COMMIT'ing only when
the client transaction commits. Would it be possible to have a simply
function which could be called to say "commit the transaction on the
foreign side for this server/table/connection/whatever"? A nice
addition on top of that would be able to define 'auto-commit' for a
given table or server.

I'll try and find time to work on this, but I'd love feedback on if this
is possible and where the landmines are.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2013-03-28 12:45:28 Re: [COMMITTERS] pgsql: Allow external recovery_config_directory
Previous Message Daniel Farina 2013-03-28 12:35:57 Re: Default connection parameters for postgres_fdw and dblink