Re: Allow workers to override datallowconn

On Thu, Mar 29, 2018 at 4:39 PM, Tomas Vondra wrote: > > > On 03/02/2018 12:16 PM, Magnus Hagander wrote: > > On Fri, Feb 23, 2018 at 7:55 PM, Magnus Hagander > > wrote: > > > > On Fri, Feb 23, 2018 at 7:52 PM,

Re: Allow workers to override datallowconn

On 03/02/2018 12:16 PM, Magnus Hagander wrote: > On Fri, Feb 23, 2018 at 7:55 PM, Magnus Hagander > wrote: > > On Fri, Feb 23, 2018 at 7:52 PM, Tom Lane > wrote: > > Magnus

Re: Allow workers to override datallowconn

On Fri, Feb 23, 2018 at 7:55 PM, Magnus Hagander wrote: > On Fri, Feb 23, 2018 at 7:52 PM, Tom Lane wrote: > >> Magnus Hagander writes: >> > Here's another attempt at moving this one forward. Basically this adds a >> > new GucSource

Re: Allow workers to override datallowconn

On Fri, Feb 23, 2018 at 7:52 PM, Tom Lane wrote: > Magnus Hagander writes: > > Here's another attempt at moving this one forward. Basically this adds a > > new GucSource being GUC_S_CLIENT_EARLY. It now runs through the > parameters > > once before

Re: Allow workers to override datallowconn

Magnus Hagander writes: > Here's another attempt at moving this one forward. Basically this adds a > new GucSource being GUC_S_CLIENT_EARLY. It now runs through the parameters > once before CheckMyDatabase, with source set to GUC_S_CLIENT_EARLY. In this > source, *only*

Re: Allow workers to override datallowconn

On Thu, Feb 22, 2018 at 9:24 PM, Tom Lane wrote: > Magnus Hagander writes: > > I hacked up an attempt to do this. It does seem to work in the very > simple > > case, but it does requiring changing the order in InitPostgres() to load > > the startup

Re: Allow workers to override datallowconn

Hi, On 2018-02-22 15:24:50 -0500, Tom Lane wrote: > You could possibly make it work with more aggressive refactoring, but > I remain of the opinion that this is a fundamentally bad idea anyhow. > A GUC of this kind is just ripe for abuse, and I don't think it's solving > any problem we really

Re: Allow workers to override datallowconn

On 2018-02-22 15:24:50 -0500, Tom Lane wrote: > Magnus Hagander writes: > > I hacked up an attempt to do this. It does seem to work in the very simple > > case, but it does requiring changing the order in InitPostgres() to load > > the startup packet before validating those.

Re: Allow workers to override datallowconn

Magnus Hagander writes: > I hacked up an attempt to do this. It does seem to work in the very simple > case, but it does requiring changing the order in InitPostgres() to load > the startup packet before validating those. I doubt that's safe. It requires, to name just one

Re: Allow workers to override datallowconn

On Thu, Feb 22, 2018 at 9:09 PM, Tom Lane wrote: > Andres Freund writes: > > The more important part I think is that we solve it via a GUC that can > > be used outside of bgworkers. > > Are you proposing an "ignore_datallowconn" GUC? That's a remarkably

Re: Allow workers to override datallowconn

Andres Freund writes: > The more important part I think is that we solve it via a GUC that can > be used outside of bgworkers. Are you proposing an "ignore_datallowconn" GUC? That's a remarkably bad idea. We don't have infrastructure that would allow it to be set at an

Re: Allow workers to override datallowconn

Magnus Hagander writes: > On Thu, Feb 22, 2018 at 8:26 PM, Andres Freund wrote: >> What's the argument against? > Complexity for the bgw usecase. They'd be completely different implementations and code paths, no? For pg_upgrade to use such a thing it'd

Re: Allow workers to override datallowconn

On 2018-02-22 20:30:02 +0100, Magnus Hagander wrote: > Complexity for the bgw usecase. It now has to construct a key/value pair > with proper escaping (well, for this one flag it would be easy, but if we > do that wouldn't we also support the other config params? Were you thinking > we'd have

Re: Allow workers to override datallowconn

On Thu, Feb 22, 2018 at 8:26 PM, Andres Freund wrote: > Hi, > > On 2018-02-22 20:24:03 +0100, Magnus Hagander wrote: > > 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

Re: Allow workers to override datallowconn

Hi, On 2018-02-22 20:24:03 +0100, Magnus Hagander wrote: > 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... Sure, but, it doesn't seem bad to offer the option to only allow this for code

Re: Allow workers to override datallowconn

On Thu, Feb 22, 2018 at 8:17 PM, Andres Freund 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

Re: Allow workers to override datallowconn

On 22 February 2018 at 18:24, Tom Lane wrote: >> Are there any other caveats in doing that this actually makes it dangerous >> to just allow bypassing it for extensions? > > Don't think so; we autovacuum such DBs anyway don't we? Yeh, there is already precedent that should

Re: Allow workers to override datallowconn

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

Re: Allow workers to override datallowconn

On Thu, Feb 22, 2018 at 7:24 PM, Tom Lane wrote: > Magnus Hagander writes: > > Attached is a patch that adds new Override versions of the functions to > > connect to a database from a background worker. > > > Another option would be to just add the

Re: Allow workers to override datallowconn

Magnus Hagander writes: > Attached is a patch that adds new Override versions of the functions to > connect to a database from a background worker. > Another option would be to just add the parameter directly to the regular > connection function, and not create separate