Re: FDW-based dblink - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: FDW-based dblink
Date
Msg-id 4A83F27F.1070008@enterprisedb.com
Whole thread Raw
In response to FDW-based dblink  (Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: FDW-based dblink  (David Fetter <david@fetter.org>)
Re: FDW-based dblink  (Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
List pgsql-hackers
Itagaki Takahiro wrote:
> Present dblink is a thin wrapper of libpq, but some of my customers
> want automatic transaction managements. Remote transactions are
> committed with 2PC when the local transaction is committed.
> To achieve it, I think we need on-commit trigger is needed,
> but it is hard to implement with current infrastructure.
> (That is one of the reason I proposed to merge dblink into core.)

Quite aside from the requirement for on-commit trigger, how exactly
would you use 2PC with the remote database? When would you issue PREPARE
TRANSACTION, and when would COMMIT PREPARED? What if the local database
crashes in between - is the remote transaction left hanging in prepared
state?

Making the remote transcation atomic with the local one is a lot harder
than it may seem at first glance. It's doable, but I think you'll need
to build a full-fledged transaction manager into dblink, or integrate
with a 3rd party one,

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: trigger functions can only be called as triggers
Next
From: Michael Meskes
Date:
Subject: Re: DECLARE doesn't set/reset sqlca after DECLARE cursor