Re: alter user set local_preload_libraries.

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: peter_e(at)gmx(dot)net
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, masao(dot)fujii(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: alter user set local_preload_libraries.
Date: 2014-09-01 11:51:59
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


> > I found this issue when trying per-pg_user (role) loading of
> > auto_analyze and some tweaking tool. It is not necessarily set by
> > the user by own, but the function to decide whether to load some
> > module by the session-user would be usable, at least, as for me:)
> I think we could just set local_preload_libraries to PGC_USERSET and
> document that subsequent changes won't take effect. That's the same way
> session_preload_libraries works. That would avoid inventing another
> very specialized GUC context.

It is enough for me. Since the only advantage of
PGC_BACKEND_USERSET is the capability to inhibit in-session
modification and I don't see another use case for it, I have no
objection for your opinion.

> If you're interested in improving this area, I also suggest you read the
> thread of
> <>.

Although I don't understand even after reading this why
local_preload_libraries was PGC_SUSET, there seems to be no
reason it should be so.

The attached patch simply changes the context for local_... to
PGC_USERSET and edits the doc.


Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
fix_local_preload_libraries_v1.patch text/x-patch 1.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2014-09-01 11:58:29 Re: pg_receivexlog and replication slots
Previous Message Andres Freund 2014-09-01 11:50:50 Re: Decoding of (nearly) empty transactions and regression tests