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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Parallel pg_dump's error reporting doesn't work worth squat
Date: 2016-05-23 17:40:30
Message-ID: 1336.1464025230@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
>> ... the pg_dump process has crashed with a SIGPIPE without printing
>> any message whatsoever, and without coming anywhere near finishing the
>> dump.

> Attached is a proposed patch for this. It reverts exit_horribly() to
> what it used to be pre-9.3, ie just print the message on stderr and die.
> The master now notices child failure by observing EOF on the status pipe.
> While that works automatically on Unix, we have to explicitly close the
> child side of the pipe on Windows (could someone check that that works?).
> I also fixed the parent side to ignore SIGPIPE earlier, so that it won't
> just die if it was in the midst of sending to the child.

Now that we're all back from PGCon ... does anyone wish to review this?
Or have an objection to treating it as a bug fix and patching all branches
back to 9.3?

> BTW, after having spent the afternoon staring at it, I will assert with
> confidence that pg_dump/parallel.c is an embarrassment to the project.

I've done a bit of work on a cosmetic cleanup patch, but don't have
anything to show yet.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2016-05-23 17:44:20 Re: Changed SRF in targetlist handling
Previous Message Tom Lane 2016-05-23 17:36:57 Re: Changed SRF in targetlist handling