Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On Tue, Oct 28, 2014 at 9:03 AM, Dilip kumar <dilip(dot)kumar(at)huawei(dot)com> wrote:
>
> On 25 October 2014 17:52, Amit Kapila Wrote,
>
> >***************
>
> >*** 358,363 **** handle_sigint(SIGNAL_ARGS)
>
> >--- 358,364 ----
>
> >
>
> > /* Send QueryCancel if we are processing a database query */
>
> > if (cancelConn != NULL)
>
> > {
>
> >+ inAbort = true;
>
> > if (PQcancel(cancelConn, errbuf, sizeof(errbuf)))
>
> > fprintf(stderr, _("Cancel request sent\n"));
>
> > else
>
> >
>
> >Do we need to set inAbort flag incase PQcancel is successful?
>
> >Basically if PQCancel fails due to any reason, I think behaviour
>
> >can be undefined as the executing thread can assume that cancel is
>
> >done.
>
> >
>
> >*** 391,396 **** consoleHandler(DWORD dwCtrlType)
>
> >--- 392,399 ----
>
> > EnterCriticalSection
>
> >(&cancelConnLock);
>
> > if (cancelConn != NULL)
>
> > {
>
> >+ inAbort =
>
> >true;
>
> >+
>
>
>
> In “handle_sigint” function if we are going to cancel the query that time
I am setting the flag inAbort (even when it is success), so that in
“select_loop” function
>

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?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com