| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Magnus Hagander <magnus(at)hagander(dot)net> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Subject: | Re: Allow workers to override datallowconn |
| Date: | 2018-02-22 20:00:23 |
| Message-ID: | 31080.1519329623@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Thu, Feb 22, 2018 at 8:26 PM, Andres Freund <andres(at)anarazel(dot)de> 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 need to be a connection parameter
of some sort (implying, eg, infrastructure in libpq), while for a bgworker
there's no such animal as connection parameters because there's no
connection.
Certainly what pg_upgrade has to do is a bit ugly, but you'd be adding
an awful lot of code to get rid of a small amount of code. Doesn't
seem like a great tradeoff. Even if it is a good tradeoff, it seems
entirely unrelated to the bgworker's problem.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-02-22 20:09:28 | Re: Allow workers to override datallowconn |
| Previous Message | Andres Freund | 2018-02-22 19:52:20 | Re: Online enabling of checksums |