Hello, sorry for the absense,
Thank you for committing.
> On 8/29/14 4:01 PM, Peter Eisentraut wrote:
> > On 8/28/14 9:01 AM, Kyotaro HORIGUCHI wrote:
> >> 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
On 8/29/14 4:01 PM, Peter Eisentraut wrote:
> On 8/28/14 9:01 AM, Kyotaro HORIGUCHI wrote:
>> 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
>> modu
On Tue, Dec 9, 2014 at 11:56 PM, Robert Haas wrote:
> On Mon, Dec 8, 2014 at 9:18 PM, Tom Lane wrote:
>> Barring someone committing to spend the time to improve that situation
>> (time that would be poorly invested IMO), I don't think that we want to
>> open up ignore_system_indexes as USERSET, o
On Mon, Dec 8, 2014 at 9:18 PM, Tom Lane wrote:
> Barring someone committing to spend the time to improve that situation
> (time that would be poorly invested IMO), I don't think that we want to
> open up ignore_system_indexes as USERSET, or do anything else to encourage
> its use.
>
> If we're in
Peter Eisentraut writes:
> On 12/8/14 12:39 PM, Robert Haas wrote:
>> On Sun, Dec 7, 2014 at 9:54 AM, Peter Eisentraut wrote:
>>> My radical proposal therefore would have been to embrace this
>>> inconsistency and get rid of PGC_BACKEND and PGC_SU_BACKEND altogether,
>>> relying on users interpre
On 12/8/14 12:39 PM, Robert Haas wrote:
> On Sun, Dec 7, 2014 at 9:54 AM, Peter Eisentraut wrote:
>> My radical proposal therefore would have been to embrace this
>> inconsistency and get rid of PGC_BACKEND and PGC_SU_BACKEND altogether,
>> relying on users interpreting the parameter names to indi
On Sun, Dec 7, 2014 at 9:54 AM, Peter Eisentraut wrote:
> My radical proposal therefore would have been to embrace this
> inconsistency and get rid of PGC_BACKEND and PGC_SU_BACKEND altogether,
> relying on users interpreting the parameter names to indicate that
> changing them later may or may no
Peter Eisentraut writes:
> My radical proposal therefore would have been to embrace this
> inconsistency and get rid of PGC_BACKEND and PGC_SU_BACKEND altogether,
> relying on users interpreting the parameter names to indicate that
> changing them later may or may not have an effect. Unfortunatel
On 11/12/14 1:01 PM, Fujii Masao wrote:
> On Wed, Nov 5, 2014 at 1:22 AM, Peter Eisentraut wrote:
>> On 10/9/14 1:58 PM, Fujii Masao wrote:
>>> Also I think that it's useful to allow ALTER ROLE/DATABASE SET to
>>> set PGC_BACKEND and PGC_SU_BACKEND parameters. So, what
>>> about applying the attac
On Wed, Nov 5, 2014 at 1:22 AM, Peter Eisentraut wrote:
> On 10/9/14 1:58 PM, Fujii Masao wrote:
>> Also I think that it's useful to allow ALTER ROLE/DATABASE SET to
>> set PGC_BACKEND and PGC_SU_BACKEND parameters. So, what
>> about applying the attached patch? This patch allows that and
>> chang
Peter Eisentraut writes:
> On 10/9/14 1:58 PM, Fujii Masao wrote:
>> Also I think that it's useful to allow ALTER ROLE/DATABASE SET to
>> set PGC_BACKEND and PGC_SU_BACKEND parameters. So, what
>> about applying the attached patch? This patch allows that and
>> changes the context of session_prelo
On 10/9/14 1:58 PM, Fujii Masao wrote:
> Also I think that it's useful to allow ALTER ROLE/DATABASE SET to
> set PGC_BACKEND and PGC_SU_BACKEND parameters. So, what
> about applying the attached patch? This patch allows that and
> changes the context of session_preload_libraries to PGC_SU_BACKEND.
On Tue, Oct 21, 2014 at 3:16 PM, Kyotaro HORIGUCHI
wrote:
> Wow.
>
>> > By the way, I became unable to login at all after wrongly setting
>> > *_preload_libraries for all available users. Is there any releaf
>> > measures for the situation? I think it's okay even if there's no
>> > way to login ag
Wow.
> > By the way, I became unable to login at all after wrongly setting
> > *_preload_libraries for all available users. Is there any releaf
> > measures for the situation? I think it's okay even if there's no
> > way to login again but want to know if any.
>
> Yep, that's a problem. You can l
On Fri, Oct 10, 2014 at 5:36 PM, Kyotaro HORIGUCHI
wrote:
> Hello, I overlooked this thread.
>
>> On Mon, Sep 15, 2014 at 1:33 AM, Tom Lane wrote:
>> > Peter Eisentraut writes:
>> >> On 9/1/14 7:51 AM, Kyotaro HORIGUCHI wrote:
>> >>> The attached patch simply changes the context for local_... to
Hello, I overlooked this thread.
> On Mon, Sep 15, 2014 at 1:33 AM, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> On 9/1/14 7:51 AM, Kyotaro HORIGUCHI wrote:
> >>> The attached patch simply changes the context for local_... to
> >>> PGC_USERSET and edits the doc.
> >
> >> I had this ready to
On Mon, Sep 15, 2014 at 1:33 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 9/1/14 7:51 AM, Kyotaro HORIGUCHI wrote:
>>> The attached patch simply changes the context for local_... to
>>> PGC_USERSET and edits the doc.
>
>> I had this ready to commit, but then
>
>> Invent PGC_SU_BACKEND
Peter Eisentraut writes:
> On 9/1/14 7:51 AM, Kyotaro HORIGUCHI wrote:
>> The attached patch simply changes the context for local_... to
>> PGC_USERSET and edits the doc.
> I had this ready to commit, but then
> Invent PGC_SU_BACKEND and mark log_connections/log_disconnections
> that way.
>
On 9/1/14 7:51 AM, Kyotaro HORIGUCHI wrote:
> The attached patch simply changes the context for local_... to
> PGC_USERSET and edits the doc.
I had this ready to commit, but then
Invent PGC_SU_BACKEND and mark log_connections/log_disconnections
that way.
was committed in the meantime.
Does
Hello,
> > 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 c
On 8/28/14 9:01 AM, Kyotaro HORIGUCHI wrote:
> 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,
Hello,
> On Thu, 2014-07-03 at 13:05 +0900, Kyotaro HORIGUCHI wrote:
> > For the earlier than 9.4, no one seems to have considered
> > seriously to use local_preload_library via ALTER statements so
> > far. Only document fix would be enough for them.
>
> I think local_preload_libraries never actu
On Thu, 2014-07-03 at 13:05 +0900, Kyotaro HORIGUCHI wrote:
> For the earlier than 9.4, no one seems to have considered
> seriously to use local_preload_library via ALTER statements so
> far. Only document fix would be enough for them.
I think local_preload_libraries never actually worked sensibly
Hello, I made a set of patches to fix this issue.
The attached files are the followings,
0001_Add_PGC_BACKEND_USERSET_v0.patch:
Add new GUC category PGC_BACKEND_USERSET and change
local_preload_libraries to use it.
0002_dblink_follow_change_of_set_config_options_v0.patch:
0003_postgres_fdw_
o
<20408.1404329...@sss.pgh.pa.us>
User-Agent: Mew version 6.5 on Emacs 22.2 / Mule 5.0
=?iso-2022-jp?B?KBskQjpnGyhCKQ==?= / Meadow-3.01-dev (TSUBO-SUMIRE)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello, I'm getting confused.. The
Fujii Masao writes:
> Agreed. I was also thinking we can set it per role, but got surprised
> when I found that's impossible. Is this a problem of only
> local_preload_libraries? I'm afraid that all PGC_BACKEND parameters
> have the same problem.
Well, there aren't that many PGC_BACKEND parameter
On Thu, Jul 3, 2014 at 3:53 AM, Tom Lane wrote:
> Fujii Masao writes:
>> On Wed, Jul 2, 2014 at 11:15 PM, Tom Lane wrote:
>>> Kyotaro HORIGUCHI writes:
postgres=# alter user horiguti2 set local_preload_libraries='libname';
ERROR: parameter "local_preload_libraries" cannot be set afte
Fujii Masao writes:
> On Wed, Jul 2, 2014 at 11:15 PM, Tom Lane wrote:
>> Kyotaro HORIGUCHI writes:
>>> postgres=# alter user horiguti2 set local_preload_libraries='libname';
>>> ERROR: parameter "local_preload_libraries" cannot be set after connection
>>> start
>> Hm ... it's kind of annoyin
On Wed, Jul 2, 2014 at 11:15 PM, Tom Lane wrote:
> Kyotaro HORIGUCHI writes:
>> postgres=# alter user horiguti2 set local_preload_libraries='libname';
>> ERROR: parameter "local_preload_libraries" cannot be set after connection
>> start
>
> Hm ... it's kind of annoying that that doesn't work; i
Kyotaro HORIGUCHI writes:
> postgres=# alter user horiguti2 set local_preload_libraries='libname';
> ERROR: parameter "local_preload_libraries" cannot be set after connection
> start
Hm ... it's kind of annoying that that doesn't work; it's certainly not
hard to imagine use-cases for per-user o
Hello, This is about a document fix of local_preload_libraries
for the versions 9.3 and earlier to at least 8.4.
There's inconsistency between documentation about
local_preload_libraries for 9.3 and earlier and their behavior.
The 9.3 document for local_preload_libraries says that:
http://www.p
31 matches
Mail list logo
