Re: Allow workers to override datallowconn

On Thu, Feb 22, 2018 at 9:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Andres Freund <andres(at)anarazel(dot)de> 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 appropriate scope. I can't imagine any good use-case for allowing
> it to be on globally; you'd want it to be per-session (or per-bgworker).
> But I don't think there's any way to change the system default setting
> in time for the setting to take effect during connection startup or
> bgworker startup.
>

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.

PFA WIP, which also shows how to do it in the background worker.

This one also lets me do

PGOPTIONS="-c ignore_connection_restrictionon" psql template0

to bypass the restriction, which is what pg_upgrade would basically do.

Magnus' most recent patch in this thread seems like a fine answer for
> bgworkers. You've moved the goalposts into the next county, and the
> design you're proposing to satisfy that goal is lousy. It will end
> up being a large amount of additional work with no benefit except
> being able to use an arguably less ugly (but almost certainly no
> shorter) datallowconn override method in pg_upgrade.
>

*If* the moving of the startup packet processing to one step earlier in
InitPostgres is safe, then it is actually less code this way right now.
From a quick look I think it's safe to move it, but I haven't looked in
detail.

I also haven't checked if this actually helps in the pg_upgrade case, but
if bypassing datallowconn is what's needed there then it shuld.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>