Re: patch for parallel pg_dump

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Joachim Wieland <joe(at)mcknight(dot)de>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: patch for parallel pg_dump
Date: 2012-04-03 16:17:25
Message-ID: 9129.1333469845@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Apr 3, 2012 at 11:59 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-04-03 16:25:20 Re: Switching to Homebrew as recommended Mac install?
Previous Message Tom Lane 2012-04-03 16:10:55 Re: patch for parallel pg_dump