Re: patch for parallel pg_dump - Mailing list pgsql-hackers

From Tom Lane
Subject Re: patch for parallel pg_dump
Date
Msg-id 9129.1333469845@sss.pgh.pa.us
Whole thread Raw
In response to Re: patch for parallel pg_dump  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: patch for parallel pg_dump
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Apr 3, 2012 at 11:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Well, if we don't have a solution to that problem then it's premature
>> to propose making Assert available to frontend code. �So my opinion
>> is that that idea is too half-baked to be pushing into 9.2 at this
>> time. �Let's put it on the to-do list instead.

> It's more baked than Joachim's existing solution, and I don't favor
> punting his whole patch because we don't want to give five minutes of
> thought to this problem.  The patch may need to be punted for other
> reasons, of course.

Ripping out the Asserts surely can't take long.

> Maybe we could just stick #ifdef BACKEND in the libpgport code.  If
> we're in the backend, we write_stderr().  Otherwise we just
> fprintf(stderr, ...).

No, the reason for write_stderr() is that fprintf(stderr) is unreliable
on Windows.  If memory serves, it can actually crash in some situations.

More generally, it's not very clear what to do with error reports in an
OS environment where stderr isn't a universally supported concept.
So (IMO anyway) you can't just ignore the problem.  And it's not one
that's going to be solved in five minutes, either.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: patch for parallel pg_dump
Next
From: Robert Haas
Date:
Subject: Re: Switching to Homebrew as recommended Mac install?