From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
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-07 03:14:31 |
Message-ID: | 20160607.121431.51138693.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Mon, 06 Jun 2016 11:12:14 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <17504(dot)1465225934(at)sss(dot)pgh(dot)pa(dot)us>
> Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> > 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>
> >> 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.
>
> Uh, what? PQcancel is very carefully coded so that it's safe to use
> in a signal handler. If it's doing mallocs someplace, that would be
> surprising.
PQcancel is disigned to run in a signal handler on *Linux*, but
the discussion here is that the equivalent of send/recv and the
similars on Windows can be blocked by the TerminateThread'ed
thread via heap lock.
> > 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?
>
> This is really ugly and I'm unconvinced that it fixes anything.
> write_msg is hardly the only place in a worker thread that might
> be doing malloc's; moreover, preventing workers from entering it
> after we start a shutdown does nothing for workers that might be
> in it already.
Yeah, it's ugly. But if we assume write() can be blocked, the
similar system calls used within PQcancel can be blocked, too. If
we don't assume so, using write instead of write_msg would do.
The problem I think is we don't have (or they don't offer?)
enough knowlegde about the inside of Windows APIs.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-06-07 03:31:59 | Re: installcheck failing on psql_crosstab |
Previous Message | Peter Eisentraut | 2016-06-07 01:45:04 | parallel workers and client encoding |