Re: pg_background (and more parallelism infrastructure patches)
От | Robert Haas |
---|---|
Тема | Re: pg_background (and more parallelism infrastructure patches) |
Дата | |
Msg-id | CA+TgmoYOihJj4TM=E6=w5B1U5Ew=tJ2wBMPLUsWHXEQoT1h6YA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_background (and more parallelism infrastructure patches) (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: pg_background (and more parallelism infrastructure
patches)
Re: pg_background (and more parallelism infrastructure patches) |
Список | 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 по дате отправления: