Re: RFC: Timing Events - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: RFC: Timing Events
Date
Msg-id 509ABA55.9030000@agliodbs.com
Whole thread Raw
In response to Re: RFC: Timing Events  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: RFC: Timing Events  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: RFC: Timing Events  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
> You're being obtuse, Josh.  These parameters can be set the same way any
> other parameters can, including ALTER ROLE SET or ALTER DATABASE SET.
> The "superuser only" restriction is that only a superuser can execute
> the ALTER, not that the target role has to be superuser.

Oh?  Ok, that's helpful.

It still eliminates the main potential use of auto-explain on production
sites, though, which is to turn it on only for specific operations.
I've never been able to make use of auto-explain for any real diagnostic
purpose on a production site, and I don't personally know anyone who has.

I recall bringing this up when auto-explain was first committed as a
fatal limitation in the module.  And as far as I'm concerned, it has been.

Fixing this would clearly be complex; we don't currently have a system
which lets the superuser control which other users can change specific
parameters, even though that would be useful in a lot of contexts.
Presumably, making auto-explain would also require such a system of
grants, so it's not something we're fixing for 9.3, I'd imagine.

To get back to the original thread, though: I'm saying that "you can do
that with auto-explain" is zero justification to limit any of Greg's
work, because auto-explain isn't generally useful.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: crash in DROP INDEX CONCURRENTLY
Next
From: Josh Berkus
Date:
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL