Re: Parallel pg_dump's error reporting doesn't work worth squat - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Parallel pg_dump's error reporting doesn't work worth squat
Date
Msg-id 11515.1464961470@sss.pgh.pa.us
Whole thread Raw
In response to Re: Parallel pg_dump's error reporting doesn't work worth squat  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: Parallel pg_dump's error reporting doesn't work worth squat  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.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.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Rename max_parallel_degree?
Next
From: Michael Paquier
Date:
Subject: Re: Problem with dumping bloom extension