Re: Allow workers to override datallowconn

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Allow workers to override datallowconn
Дата
Msg-id CABUevEwnT3do+pSez9u7oqmoz5W_uRSTN=NR-bNOtYg_5WodRw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Allow workers to override datallowconn  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Allow workers to override datallowconn
Список pgsql-hackers
On Thu, Feb 22, 2018 at 9:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andres Freund <andres@anarazel.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. 


--
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Hash Joins vs. Bloom Filters / take 2
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Online enabling of checksums