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

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

In response to

Responses

Browse pgsql-hackers by date

  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