From: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
> Yes, but it still seems hard to me that we require for all FDW
> implementations to commit/rollback prepared transactions without the
> possibility of ERROR.
Of course we can't eliminate the possibility of error, because remote servers require network communication. What I'm
sayingis to just require the FDW to return error like xa_commit(), not throwing control away with ereport(ERROR). I
don'tthink it's too strict.
> I think it's not necessarily that all FDW implementations need to be
> able to support xa_complete(). We can support both synchronous and
> asynchronous executions of prepare/commit/rollback.
Yes, I think parallel prepare and commit can be an option for FDW. But I don't think it's an option for a serious
scale-outDBMS. If we want to use FDW as part of PostgreSQL's scale-out infrastructure, we should design (if not
implementedin the first version) how the parallelism can be realized. That design is also necessary because it could
affectthe FDW API.
> If you're concerned that executing a UDF function by like 'SELECT
> myfunc();' updates data on a foreign server, since the UDF should know
> which foreign server it modifies data on it should be able to register
> the foreign server and mark as modified. Or you’re concerned that a
> UDF function in WHERE condition is pushed down and updates data (e.g.,
> ‘SELECT … FROM foreign_tbl WHERE id = myfunc()’)?
What I had in mind is "SELECT myfunc(...) FROM mytable WHERE col = ...;" Does the UDF call get pushed down to the
foreignserver in this case? If not now, could it be pushed down in the future? If it could be, it's worth considering
howto detect the remote update now.
Regards
Takayuki Tsunakawa
