Re: Allow workers to override datallowconn
| От | Magnus Hagander |
|---|---|
| Тема | Re: Allow workers to override datallowconn |
| Дата | |
| Msg-id | CABUevEzmkFz5u5isgO3-GpPNjJ-Pvuk_KhnJobhc5huoFGw1_A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Allow workers to override datallowconn (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: Allow workers to override datallowconn
|
| Список | pgsql-hackers |
On Thu, Feb 22, 2018 at 8:17 PM, Andres Freund <andres@anarazel.de> wrote:
-- Hi,
On 2018-02-22 19:01:35 +0100, Magnus Hagander wrote:
> In working on the checksumhelper patch, we came across wanting a background
> worker to be allowed to bypass datallowconn for a database. Right now we
> didn't take care of that, and just said "you have to ALTER TABLE" first.
I suspect you mean ALTER DATABASE, rather than table? ;)
Um. Yes :)
I wonder if we don't want this to be a slightly more generic
facility. E.g. pg_upgrade has the same need. Perhaps we whould
superuser-only connection-establishment only option that allows
connecting to a database even if datallowconn = false, and then
additionally allow to pass connection arguments to
BackgroundWorkerInitializeConnection()? It seems fairly reasonable to
want to establish different GUCs via normal GUC-y mechanisms when
establishing a bgworker connection...
In a background worker you can just set the parameter using SetConfigOption(), no? That seems a lot easier than turning things in to a kv pair and back...
I can see the point for having such a parameter for pg_upgrade, but I'm not sure we'd necessarily want to overload them.
В списке pgsql-hackers по дате отправления: