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. 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? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers