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-03T15:54:38Z
Lists: pgsql-hackers
On Tue, Apr 3, 2012 at 11:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Apr 3, 2012 at 10:40 AM, Joachim Wieland <joe@mcknight.de> wrote: >>> I completely agree. Assertions helped a lot dealing with concurrent >>> code. How do you want to tackle this for now? Want me to create a >>> separate header pg_assert.h as part of my patch? Or is it okay to >>> factor it out later and include it from the general header then? > >> I'll just go do it, barring objections. > > If the necessary support code isn't going to be available *everywhere*, > it should not be in postgres.h. So I did not care for your proposal to > put it in dumputils. Err... I didn't suggest putting it in postgres.h. I suggested taking it OUT of postgres.h and putting it in a separate header file. > Possibly we could move assert.c into src/port/ and make it part of > libpgport? The trouble is that it calls write_stderr(), which has a non-trivial implementation on Windows that I don't believe will be suitable for front-end code. If we can find a reasonable way to work around that issue then I think that would work. We might also want to rename ExceptionalCondition() to pg_exceptional_condition or something like that if we're going to include it in libpgport. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company