On Tue, Jul 15, 2014 at 10:45 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Wed, Jul 2, 2014 at 10:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I wrote:
>>> In short, maybe we ought to invent a new category PGC_SU_BACKEND (not
>>> wedded to this spelling), which is to PGC_BACKEND as PGC_SUSET is to
>>> PGC_USERSET, ie same when-it-can-be-changed behavior but only superusers
>>> are allowed to change it. I don't have any objection to making these two
>>> settings only adjustable by superusers --- I just don't want to give up
>>> the existing timing restrictions for them.
>>
>> Another idea would be to get rid of PGC_SUSET as a separate category, and
>> instead have a superuser-only bit in the GUC flags, which would apply to
>> all categories. This would be a bit more orthogonal, though likely a
>> much more invasive change.
>
> That could become interesting in the futuren ow that we have ALTER
> SYSTEM SET. It could allow a non-superuser to make persistent
> configuration changes. Now, I'm not sure we actually *want* that
> though... But having it as a separate bit would make it possible for
> ALTER SYSTEM SET to say that for example regular users would be able
> to change work_mem persistently. But if we want to go down that route,
> we might need a more fine grained permissions model than just
> superuser vs non-superuser...
>
> I think going with the PGC_SU_BACKEND is the right choice at this
> time, until we have an actual usecase for the other :)
Yep, the attached patch introduces PGC_SU_BACKEND and
changes the contexts of log_connections and log_disconnections
to PGC_SU_BACKEND. Review?
Regards,
--
Fujii Masao
