Re: Parallel pg_dump's error reporting doesn't work worth squat

Alvaro Herrera <alvherre(at)2ndquadrant(dot)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.GB1663@alvh.no-ip.org

Hmm, did the patch you're discussing there get committed?

regards, tom lane