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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: alvherre(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Parallel pg_dump's error reporting doesn't work worth squat
Date: 2016-06-03 13:44:30
Message-ID: 11515.1464961470@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-06-03 13:44:38 Re: Problem with dumping bloom extension
Previous Message Tom Lane 2016-06-03 13:39:43 Re: Rename max_parallel_degree?