| From: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
|---|---|
| To: | 'Kyotaro Horiguchi' <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | "ashutosh(dot)bapat(dot)oss(at)gmail(dot)com" <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, "masahiko(dot)sawada(at)2ndquadrant(dot)com" <masahiko(dot)sawada(at)2ndquadrant(dot)com>, "sawada(dot)mshk(at)gmail(dot)com" <sawada(dot)mshk(at)gmail(dot)com>, "masao(dot)fujii(at)oss(dot)nttdata(dot)com" <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, "amit(dot)kapila16(at)gmail(dot)com" <amit(dot)kapila16(at)gmail(dot)com>, "m(dot)usama(at)gmail(dot)com" <m(dot)usama(at)gmail(dot)com>, "ikedamsh(at)oss(dot)nttdata(dot)com" <ikedamsh(at)oss(dot)nttdata(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "sulamul(at)gmail(dot)com" <sulamul(at)gmail(dot)com>, "alvherre(at)2ndquadrant(dot)com" <alvherre(at)2ndquadrant(dot)com>, "thomas(dot)munro(at)gmail(dot)com" <thomas(dot)munro(at)gmail(dot)com>, "ildar(at)adjust(dot)com" <ildar(at)adjust(dot)com>, "horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp" <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "chris(dot)travers(at)adjust(dot)com" <chris(dot)travers(at)adjust(dot)com>, "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "ishii(at)sraoss(dot)co(dot)jp" <ishii(at)sraoss(dot)co(dot)jp> |
| Subject: | RE: Transactions involving multiple postgres foreign servers, take 2 |
| Date: | 2020-10-20 04:23:12 |
| Message-ID: | TYAPR01MB29907BF7A661E3E1DD471C95FE1F0@TYAPR01MB2990.jpnprd01.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
> I don't think the inability to cancel all session at once cannot be a
> reason not to not to allow operators to cancel a stuck session.
Yeah, I didn't mean to discount the ability to cancel queries. I just want to confirm how the user can use the cancellation in practice. I didn't see how the user can use the cancellation in the FDW framework, so I asked about it. We have to think about the user's context if we regard canceling commits as important.
> > Furthermore, FDW is not cancellable in general. So, I don't see a point in
> trying hard to make only commit be cancelable.
>
> I think that it is quite important that operators can cancel any
> process that has been stuck for a long time. Furthermore, postgres_fdw
> is more likely to be stuck since network is involved so the usefulness
> of that feature would be higher.
But lower than practical performance during normal operation.
BTW, speaking of network, how can postgres_fdw respond quickly to cancel request when libpq is waiting for a reply from a down foreign server? Can the user continue to use that session after cancellation?
Regards
Takayuki Tsunakawa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2020-10-20 05:29:56 | Re: Track statistics for streaming of in-progress transactions |
| Previous Message | Peter Smith | 2020-10-20 04:14:42 | Re: [HACKERS] logical decoding of two-phase transactions |