Re: patch for parallel pg_dump

On Tue, Apr 3, 2012 at 12:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

Yeah, but asserts exist for a reason: to make it possible to find bugs
more easily. Let's not be penny-wise and pound-foolish.

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

Dude, we're already doing fprintf(stderr) all over pg_dump. If it's
unreliable even in front-end code, we're screwed anyway. That is a
non-objection.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company