From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_background (and more parallelism infrastructure patches) |
Date: | 2014-10-24 17:21:51 |
Message-ID: | CA+TgmoYOihJj4TM=E6=w5B1U5Ew=tJ2wBMPLUsWHXEQoT1h6YA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 24, 2014 at 1:13 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Pflug | 2014-10-24 17:28:24 | Re: Question about RI checks |
Previous Message | Josh Berkus | 2014-10-24 17:18:34 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |