Re: patch for parallel pg_dump
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Joachim Wieland <joe@mcknight.de>, Alvaro Herrera <alvherre@commandprompt.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Andrew Dunstan <andrew@dunslane.net>
Date: 2012-04-03T16:28:01Z
Lists: pgsql-hackers
On Tue, Apr 3, 2012 at 12:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. 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