From: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
> So with your idea, I think we require FDW developers to not call
> ereport(ERROR) as much as possible. If they need to use a function
> including palloc, lappend etc that could call ereport(ERROR), they
> need to use PG_TRY() and PG_CATCH() and return the control along with
> the error message to the transaction manager rather than raising an
> error. Then the transaction manager will emit the error message at an
> error level lower than ERROR (e.g., WARNING), and call commit/rollback
> API again. But normally we do some cleanup on error but in this case
> the retrying commit/rollback is performed without any cleanup. Is that
> right? I’m not sure it’s safe though.
Yes. It's legitimate to require the FDW commit routine to return control, because the prepare of 2PC is a promise to
commitsuccessfully. The second-phase commit should avoid doing that could fail. For example, if some memory is needed
forcommit, it should be allocated in prepare or before.
> IIUC aggregation functions can be pushed down to the foreign server
> but I have not idea the normal UDF in the select list is pushed down.
> I wonder if it isn't.
Oh, that's the current situation. Understood. I thought the UDF call is also pushed down, as I saw Greenplum does so.
(Reading the manual, Greenplum disallows data updates in the UDF when it's executed on the remote segment server.)
(Aren't we overlooking something else that updates data on the remote server while the local server is unaware?)
Regards
Takayuki Tsunakawa