Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]
| От | Amit Kapila |
|---|---|
| Тема | Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ] |
| Дата | |
| Msg-id | CAA4eK1K=8_1vEUpFYUnnwvh-Yx-PyY1-3LjfThQdWkS3kVRWYg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ] (Dilip kumar <dilip.kumar@huawei.com>) |
| Список | pgsql-hackers |
On Tue, Oct 28, 2014 at 9:27 AM, Dilip kumar <dilip.kumar@huawei.com> wrote:
> 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.
>
Yeah, user has tried to terminate, however utility will emit the
message: "Could not send cancel request" in such a case and still
> 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.
>
message: "Could not send cancel request" in such a case and still
silently tries to cancel and disconnect all connections.
run_parallel_vacuum()
{
..
for (cell = tables->head; cell; cell = cell->next)
{
/*
* This will give the free connection slot, if no slot is free it will
* wait for atleast one slot to get free.
*/
free_slot = GetIdleSlot(connSlot, max_slot, dbname, progname,
completedb);
if (free_slot == NO_SLOT)
{
error = true;
goto fail;
}
prepare_command(connSlot[free_slot].connection, full, verbose,
and_analyze, analyze_only, freeze, &sql);
appendPQExpBuffer(&sql, " %s", cell->val);
connSlot[free_slot].isFree = false;
slotconn = connSlot[free_slot].connection;
PQsendQuery(slotconn, sql.data);
resetPQExpBuffer(&sql);
}
..
}
One other related point is that I think still cancel handling mechanism
is not completely right, code is doing that when there are not enough
number of freeslots, but otherwise it won't handle the cancel request,
basically I am referring to below part of code:
{
..
for (cell = tables->head; cell; cell = cell->next)
{
/*
* This will give the free connection slot, if no slot is free it will
* wait for atleast one slot to get free.
*/
free_slot = GetIdleSlot(connSlot, max_slot, dbname, progname,
completedb);
if (free_slot == NO_SLOT)
{
error = true;
goto fail;
}
prepare_command(connSlot[free_slot].connection, full, verbose,
and_analyze, analyze_only, freeze, &sql);
appendPQExpBuffer(&sql, " %s", cell->val);
connSlot[free_slot].isFree = false;
slotconn = connSlot[free_slot].connection;
PQsendQuery(slotconn, sql.data);
resetPQExpBuffer(&sql);
}
..
}
I am wondering if it would be better to setcancelconn in above loop.
В списке pgsql-hackers по дате отправления: