On Sat, May 28, 2016 at 5:06 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Alvaro Herrera <alvhe...@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.gb1...@alvh.no-ip.org > > Hmm, did the patch you're discussing there get committed? > Yes, it was committed - a1792320 With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
