Re: Allow workers to override datallowconn

From: Andres Freund <andres(at)anarazel(dot)de>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: 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 19:44:33
Message-ID: 20180222194433.msex5lqsf2ujj26q@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 *just* tihs one?). Basically taking a data that you have in a
> "structured format" in the btw already turning it to a string and then
> parsing it back into structured data in the same string.

The serialization problem seems out of scope, I don't see why this code
would need to deal with it. Receiving the options would be pretty easy,
we pretty much have the relevant code for PGOPTIONS handling.

The more important part I think is that we solve it via a GUC that can
be used outside of bgworkers. Whether we require setting it via
set_config() for bgworkers or have option parsing doesn't matter that
much.

> I think it'd be cleaner to let the bgw initializer pass those as flags. A
> "user connection" parameter could still use the booelan in InitPostgres()
> of course, and not invent a new things there, but the entry point API could
> stay simpler.

I'm pretty strongly against having a special case flag for bgw
initialization for this.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-02-22 19:52:04 Re: ERROR: left and right pathkeys do not match in mergejoin
Previous Message Magnus Hagander 2018-02-22 19:44:17 Re: Online enabling of checksums