Again, what are we trying to achieve?!
no idea - wondering about that myself...
It seems we are trying to add grammar for modifying postgresql.conf.
Something we can already do easily in a standard extension, but without
grammar changes.
Maybe better to provide a contrib/ to modify config,
=?iso-8859-1?q?C=E9dric_Villemain?= ced...@2ndquadrant.com writes:
Again, what are we trying to achieve?!
no idea - wondering about that myself...
It seems we are trying to add grammar for modifying postgresql.conf.
Something we can already do easily in a standard extension, but without
On Tue, Aug 6, 2013 at 12:40:12PM +0200, Cédric Villemain wrote:
Again, what are we trying to achieve?!
no idea - wondering about that myself...
It seems we are trying to add grammar for modifying postgresql.conf.
Something we can already do easily in a standard extension, but without
There seemed to be agreement on having a config.d, though.
Yes.
Also, the validate_conf_parameter() (or some similar name) Amit added in his
patch sounds useful if an extension can use it (to check a GUC someone want to
change, to check a configuration file, ...)
--
Cédric Villemain +33 (0)6
* Tom Lane (t...@sss.pgh.pa.us) wrote:
=?iso-8859-1?q?C=E9dric_Villemain?= ced...@2ndquadrant.com writes:
Maybe better to provide a contrib/ to modify config, then design what we
can
achieve more with an ALTER SYSTEM command.
Hmm ... putting the UI into a contrib module would neatly
On Tue, Aug 6, 2013 at 10:58:52AM -0400, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
=?iso-8859-1?q?C=E9dric_Villemain?= ced...@2ndquadrant.com writes:
Maybe better to provide a contrib/ to modify config, then design what we
can
achieve more with an ALTER SYSTEM
On 08/06/2013 05:29 AM, Bruce Momjian wrote:
Let's look at the problems:
* remote users can lock themselves out of the server
* interconnected GUC variables are complex to change
* need a way to disable this feature
Given the above, I am not sure I see a way forward for ALTER SYSTEM
On Tue, Aug 6, 2013 at 10:33:20AM -0700, Josh Berkus wrote:
On 08/06/2013 05:29 AM, Bruce Momjian wrote:
Let's look at the problems:
* remote users can lock themselves out of the server
* interconnected GUC variables are complex to change
* need a way to disable this feature
Josh Berkus escribió:
(2) Enabling DBAAS services to give users limited control over settings.
(5) Enabling new ways of writing Puppet/Chef/etc. scripts, which can
check a setting before changing it.
Surely these two cases are better covered by conf.d. For (2), DBaaS
providers could offer
On Tue, Aug 6, 2013 at 3:31 PM, Bruce Momjian br...@momjian.us wrote:
I'd like to look at use cases, and let's see how ALTER SYSTEM SET
addresses or doesn't address these use cases. I'd really like it if
some other folks also posted use cases they know of.
(1) Making is easier for GUIs to
All:
(this thread concerns argument (F) whether or not admins need a way to
disable ALTER SYSTEM SET)
On 08/01/2013 04:03 PM, Dimitri Fontaine wrote: If only we could
trigger some actions when a command is about to be
executed, in a way that it's easy for the user to implement whatever
policy
On Mon, Aug 5, 2013 at 11:16:24AM -0700, Josh Berkus wrote:
I don't see this as a solution at all. Mr. Sysadmin, we've given the
DBAs a new tool which allows them to override your version-controlled
database parameter settings. You can turn it off, though, by using this
incredibly
* Bruce Momjian (br...@momjian.us) wrote:
On Mon, Aug 5, 2013 at 11:16:24AM -0700, Josh Berkus wrote:
I don't think this is a small thing. I really think we'll get a LOT of
blowback from sysadmins -- and maybe even refusals to upgrade -- if we
On Mon, Aug 5, 2013 at 02:52:40PM -0400, Stephen Frost wrote:
However,
frankly, these are flat files, so I don't see a problem with having the
administrator modify the flat file.
Admins on Ubuntu or Debian or a host of their derivatives aren't going
to be looking in $PGDATA for config
Bruce Momjian br...@momjian.us writes:
Well, can you assume that if you have a problem with one of your ALTER
SYSTEM SET commands, that disabling _all_ of them is going to get you a
running system? I question that, e.g. port. With postgresql.conf, you
can modify the bad entry, but how would
Tom Lane escribió:
What Josh seems to be concerned with in this thread is the question of
whether we should support an installation *policy decision* not to allow
ALTER SYSTEM SET. Not because a particular set of parameters is broken,
but just because somebody is afraid the DBA might break
Hi,
I'm now completely lost in the current threads. Is there a single valid
use case for the feature we're trying to design? Who is the target
audience of this patch?
Josh Berkus j...@agliodbs.com writes:
I don't see this as a solution at all. Mr. Sysadmin, we've given the
DBAs a new tool
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane escribió:
What Josh seems to be concerned with in this thread is the question of
whether we should support an installation *policy decision* not to allow
ALTER SYSTEM SET. Not because a particular set of parameters is broken,
but just
On Mon, 5 Aug 2013 15:53:01 -0400
Alvaro Herrera alvhe...@2ndquadrant.com wrote:
The other issue is that currently you can only edit a server's config
if you are logged in to it. If we permit SQL-level access to that,
and somebody who doesn't have access to edit the files blocks
themselves
On 08/05/2013 10:18 PM, Dimitri Fontaine wrote:
Hi,
I'm now completely lost in the current threads. Is there a single valid
use case for the feature we're trying to design? Who is the target
audience of this patch?
wonder about that myself...
Josh Berkus j...@agliodbs.com writes:
I
On 08/05/2013 09:53 PM, Alvaro Herrera wrote:
Tom Lane escribió:
What Josh seems to be concerned with in this thread is the question of
whether we should support an installation *policy decision* not to allow
ALTER SYSTEM SET. Not because a particular set of parameters is broken,
but just
Stefan,
thinking more about that - is there _ANY_ prerequisite of an application
that can be completely reconfigured over a remote access protocol and
solved the reliability and security challenges of that to a reasonable
degree?
Good question!
I also think that, given the issues raised in
On Mon, Aug 5, 2013 at 03:53:01PM -0400, Alvaro Herrera wrote:
The other issue is that currently you can only edit a server's config if
you are logged in to it. If we permit SQL-level access to that, and
somebody who doesn't have access to edit the files blocks themselves
out, there is no
23 matches
Mail list logo
