From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Satoshi Nagayasu <snaga(at)uptime(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fix to expose a GUC variable, Log_disconnections, to outside of postgres.c |
Date: | 2015-07-09 06:30:00 |
Message-ID: | 559E14E8.6050400@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 07/09/2015 07:19 AM, Satoshi Nagayasu wrote:
>
> On 2015/07/09 13:06, Tom Lane wrote:
>> Satoshi Nagayasu <snaga(at)uptime(dot)jp> writes:
>>> I just found that Log_disconnections value has not been
>>> exposed to outside of postgres.c.
>>> Despite that, Log_connections has already been exposed.
>>
>> Why would an external module need to touch either one?
>
> To check settings of GUC variables from a shared preload
> library.
>
> For example, I'd like to print "WARNING ...." in _PG_init()
> when some GUC variable is disabled on postmaster startup.
I still have a hard time seeing why an extension would be interested in
Log_disconnections. But hey, extensions do strange things..
You could use GetConfigOption(). I'm not necessarily opposed to exposing
Log_disconnections, but with GetConfigOption() it will work with earlier
versions too.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2015-07-09 06:37:58 | Re: optimizing vacuum truncation scans |
Previous Message | Amit Langote | 2015-07-09 05:53:19 | Comment nitpicking in predicate_refuted_by_recurse() |