Re: pg_background (and more parallelism infrastructure patches) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pg_background (and more parallelism infrastructure patches)
Date
Msg-id CA+TgmoYOihJj4TM=E6=w5B1U5Ew=tJ2wBMPLUsWHXEQoT1h6YA@mail.gmail.com
Whole thread Raw
In response to Re: pg_background (and more parallelism infrastructure patches)  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: pg_background (and more parallelism infrastructure patches)
Re: pg_background (and more parallelism infrastructure patches)
List pgsql-hackers
On Fri, Oct 24, 2014 at 1:13 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> It's a valid concern, but I think the way to handle it if needed is to limit
> the number of connections a user can open. Or perhaps another option would
> be to change the permissions on the related functions (do we check ACLs for
> internal functions?)

I'm not sure dump-and-restore would preserve any properties of
anything in pg_catalog.

Anyway, I think we're getting a bit ahead of ourselves here.  The
questions I need answers to right now are:

- What should we call dsm_unkeep_mapping, if not that?
- Are there remaining complaints about patch #3?
- How can I get somebody to review patch #4?
- Does anyone have a tangible suggestion for how to reduce the code
duplication in patch #6?

The question of where pg_background should ultimately live does
matter, but the answer will be "the -hackers mailing list archives"
unless we can get agreement on the prerequisite patches.

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



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Next
From: Florian Pflug
Date:
Subject: Re: Question about RI checks