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

How about silencing the workers on termination?

# Build on Windows (with VC?) is very time consuming...

At Fri, 03 Jun 2016 09:44:30 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <11515(dot)1464961470(at)sss(dot)pgh(dot)pa(dot)us>
> Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> > For sure, any of the "dangers" of TerminateThread don't matter
> > for this case.
>
> I think that this one:
>
> >> If the target thread is allocating memory from the heap, the heap
> >> lock will not be released.
>
> is potentially a hazard, which is why I made sure to use write_stderr
> later on in the console interrupt handler. Your original suggestion
> to use write_msg would end up going through fprintf, which might well
> use malloc internally. (It's possible that Windows' version of write()
> could too, I suppose, but that's probably as low-level as we are
> going to get.)

I have to admit that I forgot about the possible malloc's, and
PQcancel() can be blocked from the same reason. What is worse,
even if we managed to avoid this particular disaster, the MSDN
page says the problems are *for example*. So if we don't allow
any possible unknown blocking on ctrl-C termination and want to
forcibly terminate workers, we might have to use process instead
of thread for worker entity. (This might reduce the difference
related to WIN32..)

We also might be able to cause immediate process termination for
the second Ctrl-C but this seems to lead to other issues.

If the issue to be settled here is the unwanted error messages,
we could set a flag to instruct write_msg to sit silent. Anyway
the workers should have been dead that time so discarding any
error messages don't matter.

What do you think about this?

Timeout for select still seems to be needless.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center