From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Joachim Wieland <joe(at)mcknight(dot)de>, 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 15:56:46 |
Message-ID: | 1333468540-sup-7880@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Excerpts from Tom Lane's message of mar abr 03 12:38:20 -0300 2012:
>
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Tue, Apr 3, 2012 at 10:40 AM, Joachim Wieland <joe(at)mcknight(dot)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.
>
> Possibly we could move assert.c into src/port/ and make it part of
> libpgport?
That only leaves assert_enabled to be handled. In the backend it lives
in guc.c; what to do about frontend code?
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-04-03 15:59:36 | Re: patch for parallel pg_dump |
Previous Message | Christopher Browne | 2012-04-03 15:56:26 | Re: Switching to Homebrew as recommended Mac install? |