| From: | Dilip kumar <dilip(dot)kumar(at)huawei(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Jan Lentfer <Jan(dot)Lentfer(at)web(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br> |
| Subject: | Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ] |
| Date: | 2014-10-28 03:57:44 |
| Message-ID: | 4205E661176A124FAF891E0A6BA9135266368EB1@szxeml509-mbs.china.huawei.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 28 October 2014 09:18, Amit Kapila Wrote,
>I am worried about the case if after setting the inAbort flag,
>PQCancel() fails (returns error).
>
>> If select(maxFd + 1, workerset, NULL, NULL, &tv); come out, we can know whether it came out because of cancel query and handle it accordingly.
>>
>
>Yeah, it is fine for the case when PQCancel() is successful, what
>if it fails?
>I think even if select comes out due to any other reason, it will behave
>as if it came out due to Cancel, even though actually Cancel is failed,
>how are planning to handle that case?
I think If PQcancel fails then also there is no problem, because we are setting inAbort flag in handle_sigint handler, it means user have tried to terminate.
So in this case as well we will find that inAbort is set so we return error, and in error case we finally call DisconnectDatabase, and in this function we will send the PQcancel for all active connection and then only we disconnect.
Regards,
DIlip
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2014-10-28 04:14:52 | Re: Scaling shared buffer eviction |
| Previous Message | Amit Kapila | 2014-10-28 03:48:27 | Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ] |