On Sat, May 28, 2016 at 5:06 AM, Tom Lane <
tgl@sss.pgh.pa.us> wrote:
>
> Alvaro Herrera <
alvherre@2ndquadrant.com> writes:
> > Regarding this:
> >> + * XXX this certainly looks useless, why not just wait indefinitely?
>
> > There's another select_loop() in vacuumdb.c suggesting that the timeout
> > is used to check for cancel requests; as I understood while working on
> > the vacuumdb changes, select() is not interrupted in that case. I
> > suppose that means it's necessary here also. But on the other hand it's
> > quite possible that the original developer just copied what was in
> > pg_dump and that it's not actually needed; if that's the case, perhaps
> > it's better to rip it out from both places.
>
> Ah, interesting. That ties into something else I was wondering about,
> which is how we could get useful control-C cancellation on Windows.
> It looks like the vacuumdb.c version of this code actually is tied
> into an interrupt handler, but whoever copied it for parallel.c just
> ripped out the CancelRequested checks, making the looping behavior
> pretty useless.
>
It seems to me that CancelRequested checks were introduced in vacuumdb.c as part of commit a1792320 and select_loop for parallel.c version exists from commit 9e257a18 which got committed earlier. I think control-C handling for Windows in parallel.c is missing or if there is some way to deal with it, clearly it is not same as what we do in vacuumdb.c.
> For pg_restore (parallel or not) it would be useful if the program
> didn't just fall over at control-C but actually sent cancel requests
> to the backend(s). It's not such a problem if we're transferring
> data, but if we're waiting for some slow operation like CREATE INDEX,
> the current behavior isn't very good. On the Unix side we have some
> SIGINT infrastructure there already, but I don't see any for Windows.
>
> So now I'm thinking we should leave that alone, with the expectation
> that we'll be putting CancelRequested checks back in at some point.
>
> >
https://www.postgresql.org/message-id/20150122174601.GB1663@alvh.no-ip.org>
> Hmm, did the patch you're discussing there get committed?
>
Yes, it was committed - a1792320