| From: | Kuwamura Masaki <kuwamura(at)db(dot)is(dot)i(dot)nagoya-u(dot)ac(dot)jp> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
| Cc: | Jelte Fennema <postgres(at)jeltef(dot)nl>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, etsuro(dot)fujita(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Issue in postgres_fdw causing unnecessary wait for cancel request reply |
| Date: | 2023-07-27 11:01:56 |
| Message-ID: | CAMyC8qrjv2=oSV6bNC6TWbb01SyW1Se7Lyy7gZFfpVH5bCB6-w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi, Fujii-san
> Regarding the WARNING message, another idea is to pass the return value
> of PQgetCancel() directly to PQcancel() as follows. If NULL is passed,
> PQcancel() will detect it and set the proper error message to errbuf.
> Then the warning message "WARNING: could not send cancel request:
> PQcancel() -- no cancel object supplied" is output.
I agree to go with this.
With this approach, the information behind the error (e.g., "out of
memory") will disappear, I guess.
I think we have to deal with it eventually. (I'm sorry, I don't have a good
idea right now)
However, the original issue is unnecessary waiting, and this should be
fixed soon.
So it is better to fix the problem this way and discuss retaining
information in another patch IMO.
I'm afraid I'm new to reviewing.
If I'm misunderstanding something, please let me know.
Masaki Kuwamura
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthias van de Meent | 2023-07-27 11:59:13 | Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan |
| Previous Message | Nikita Malakhov | 2023-07-27 10:56:42 | Re: POC: Extension for adding distributed tracing - pg_tracing |