| From: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
|---|---|
| To: | 'Masahiko Sawada' <masahiko(dot)sawada(at)2ndquadrant(dot)com> |
| Cc: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Muhammad Usama <m(dot)usama(at)gmail(dot)com>, Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, amul sul <sulamul(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Ildar Musin <ildar(at)adjust(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Chris Travers <chris(dot)travers(at)adjust(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
| Subject: | RE: Transactions involving multiple postgres foreign servers, take 2 |
| Date: | 2020-09-24 08:23:25 |
| Message-ID: | TYAPR01MB29908BF2E58352C87571B068FE390@TYAPR01MB2990.jpnprd01.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)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 commit successfully. The second-phase commit should avoid doing that could fail. For example, if some memory is needed for commit, 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | k.jamison@fujitsu.com | 2020-09-24 08:47:06 | RE: [Patch] Optimize dropping of relation buffers using dlist |
| Previous Message | Michael Paquier | 2020-09-24 08:11:03 | Re: 回复：how to create index concurrently on partitioned table |