On 19 November 2013 09:59 Amit Kapila wrote:
On Mon, Nov 18, 2013 at 8:31 PM, Haribabu kommi
haribabu.ko...@huawei.com wrote:
On 18 November 2013 20:01 Amit Kapila wrote:
Code changes are fine.
If two or three errors are present in the configuration file, it
prints the last error
On Tue, Nov 19, 2013 at 2:06 PM, Haribabu kommi
haribabu.ko...@huawei.com wrote:
On 19 November 2013 09:59 Amit Kapila wrote:
On Mon, Nov 18, 2013 at 8:31 PM, Haribabu kommi
haribabu.ko...@huawei.com wrote:
On 18 November 2013 20:01 Amit Kapila wrote:
Code changes are fine.
If two or
On 17 November 2013 12:25 Amit Kapila wrote:
On Sat, Nov 16, 2013 at 4:35 PM, Haribabu kommi
haribabu.ko...@huawei.com wrote:
On 16 November 2013 09:43 Amit Kapila wrote:
On Fri, Nov 15, 2013 at 10:18 PM, Peter Eisentraut pete...@gmx.net
wrote:
On 11/14/13, 2:50 AM, Amit Kapila wrote:
On Mon, Nov 18, 2013 at 6:28 PM, Haribabu kommi
haribabu.ko...@huawei.com wrote:
On 17 November 2013 12:25 Amit Kapila wrote:
On Sat, Nov 16, 2013 at 4:35 PM, Haribabu kommi
Find the rebased version attached with this mail.
ereport(ERROR,
On 18 November 2013 20:01 Amit Kapila wrote:
On Mon, Nov 18, 2013 at 6:28 PM, Haribabu kommi
haribabu.ko...@huawei.com wrote:
On 17 November 2013 12:25 Amit Kapila wrote:
On Sat, Nov 16, 2013 at 4:35 PM, Haribabu kommi
Find the rebased version attached with this mail.
On Mon, Nov 18, 2013 at 8:31 PM, Haribabu kommi
haribabu.ko...@huawei.com wrote:
On 18 November 2013 20:01 Amit Kapila wrote:
Code changes are fine.
If two or three errors are present in the configuration file, it
prints the last error
Configuration parameter file only. Is it required to
On 16 November 2013 09:43 Amit Kapila wrote:
On Fri, Nov 15, 2013 at 10:18 PM, Peter Eisentraut pete...@gmx.net
wrote:
On 11/14/13, 2:50 AM, Amit Kapila wrote:
Find the rebased version attached with this mail.
Doesn't build:
openjade -wall -wno-unused-param -wno-empty
On Sat, Nov 16, 2013 at 4:35 PM, Haribabu kommi
haribabu.ko...@huawei.com wrote:
On 16 November 2013 09:43 Amit Kapila wrote:
On Fri, Nov 15, 2013 at 10:18 PM, Peter Eisentraut pete...@gmx.net
wrote:
On 11/14/13, 2:50 AM, Amit Kapila wrote:
Find the rebased version attached with this mail.
On 11/14/13, 2:50 AM, Amit Kapila wrote:
Find the rebased version attached with this mail.
Doesn't build:
openjade -wall -wno-unused-param -wno-empty -wfully-tagged -D . -D . -c
/usr/share/sgml/docbook/stylesheet/dsssl/modular/catalog -d stylesheet.dsl -t
sgml -i output-html -V html-index
On Fri, Nov 15, 2013 at 10:18 PM, Peter Eisentraut pete...@gmx.net wrote:
On 11/14/13, 2:50 AM, Amit Kapila wrote:
Find the rebased version attached with this mail.
Doesn't build:
openjade -wall -wno-unused-param -wno-empty -wfully-tagged -D . -D . -c
On 01 October 2013 00:56 Amit Kapila wrote:
On Mon, Sep 30, 2013 at 9:07 PM, Peter Eisentraut pete...@gmx.net
wrote:
On 9/28/13 3:05 AM, Amit Kapila wrote:
Now as we have an agreement, I had updated patch for below left
issues:
Regression tests are failing.
Thanks for informing. I
On Wed, Nov 13, 2013 at 4:05 PM, Haribabu kommi
haribabu.ko...@huawei.com wrote:
On 01 October 2013 00:56 Amit Kapila wrote:
On Mon, Sep 30, 2013 at 9:07 PM, Peter Eisentraut pete...@gmx.net
wrote:
On 9/28/13 3:05 AM, Amit Kapila wrote:
Now as we have an agreement, I had updated patch for
On Wed, Nov 13, 2013 at 7:23 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Wed, Nov 13, 2013 at 4:05 PM, Haribabu kommi
haribabu.ko...@huawei.com wrote:
On 01 October 2013 00:56 Amit Kapila wrote:
On Mon, Sep 30, 2013 at 9:07 PM, Peter Eisentraut pete...@gmx.net
wrote:
On 9/28/13 3:05
On 9/28/13 3:05 AM, Amit Kapila wrote:
Now as we have an agreement, I had updated patch for below left issues:
Regression tests are failing.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Mon, Sep 30, 2013 at 9:07 PM, Peter Eisentraut pete...@gmx.net wrote:
On 9/28/13 3:05 AM, Amit Kapila wrote:
Now as we have an agreement, I had updated patch for below left issues:
Regression tests are failing.
Thanks for informing. I am sorry for not running regression before
sending
On Fri, Aug 30, 2013 at 8:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Stephen Frost sfr...@snowman.net writes:
* Robert Haas (robertmh...@gmail.com) wrote:
I think you're getting way too hung up on the fact that the proposed
auto.conf will be stored as a flat file. From your comments upthread,
Le jeudi 29 août 2013 18:42:13 Stephen Frost a écrit :
On Thursday, August 29, 2013, Andres Freund wrote:
If you don't want your installation to use it, tell you ops people not
to do so. They are superusers, they need to have the ability to follow
some rules you make up internally.
The
Stephen Frost sfr...@snowman.net writes:
The OPs people are the ones that will be upset with this because the DBAs
will be modifying configs which OPs rightfully claim as theirs.
If that's the problem you want to solve, there's no technical solution
that will put you at ease. That's a people
Hi,
On 2013-08-30 10:20:48 +0200, Cédric Villemain wrote:
The energy wasted in a good part of this massive 550+ messages thread is
truly saddening. We all (c|sh)ould have spent that time making PG more
awesome instead.
Perhaps not understood by all, but keeping PG awesome involves
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Stephen Frost sfr...@snowman.net writes:
The OPs people are the ones that will be upset with this because the DBAs
will be modifying configs which OPs rightfully claim as theirs.
If that's the problem you want to solve, there's no
* Cédric Villemain (ced...@2ndquadrant.com) wrote:
ALTER ROLE ALL may be good enougth to handle every GUC that we can also
remove
from postgresql.conf (I suppose all GUC needing only a reload, not a
restart).
It may needs some improvement to handle changing default for ALL and adding
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2013-08-30 10:20:48 +0200, Cédric Villemain wrote:
Grammar can be added later when the feature is stable.
Could you explain the advantages of this? It will require users to get
used to different interfaces and we will end up maintaining
On 2013-08-30 08:48:21 -0400, Stephen Frost wrote:
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Stephen Frost sfr...@snowman.net writes:
The OPs people are the ones that will be upset with this because the DBAs
will be modifying configs which OPs rightfully claim as theirs.
If
On 2013-08-29 21:26:48 -0400, Stephen Frost wrote:
Sure, you can construct a scenario where this matters. The ops guys
have sudo postgres pg_ctl access but adminpack isn't installed and
they have no other way to modify the configuration file. But that's
just bizarre. And if that's
On Thu, Aug 29, 2013 at 9:12 PM, Stephen Frost sfr...@snowman.net wrote:
You will not find me argueing to allow that in normal operation, or most
direct-catalog hacking. I'd be much happier if we had all the ALTER,
etc, options necessary to prevent any need to ever touch the catalogs.
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2013-08-30 08:48:21 -0400, Stephen Frost wrote:
I really just don't buy that- I've already put forward suggestions for
how to deal with it, but no one here seems to understand the
distinction. Modifying listen_addresses through ALTER
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2013-08-29 21:26:48 -0400, Stephen Frost wrote:
It's not the OPs guy that I'm worried about using ALTER SYSTEM- I don't
expect them to have any clue about it or care about it, except where it
can be used to modify things under /etc which
On 2013-08-30 09:19:42 -0400, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2013-08-30 08:48:21 -0400, Stephen Frost wrote:
I really just don't buy that- I've already put forward suggestions for
how to deal with it, but no one here seems to understand the
On Thu, Aug 29, 2013 at 9:26 PM, Stephen Frost sfr...@snowman.net wrote:
In the first place, modifying postgresql.conf and not immediately
restarting the server to test your changes is probably the single most
basic DBA error imaginable.
You're not modifying postgresql.conf with ALTER SYSTEM,
On Fri, Aug 30, 2013 at 8:53 AM, Stephen Frost sfr...@snowman.net wrote:
Yes, one of the issues with the existing system is that you can't
specify a default to be applied to new roles. Also, there are
parameters which are not per-role yet which it probably makes sense to
be in the database
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2013-08-30 09:19:42 -0400, Stephen Frost wrote:
wal_level and shared_buffers I can buy, but listen_addresses? The most
typical change there is going from localhost - '*', but you've got to
be on the box to do that. Anything else and
On 2013-08-30 09:43:01 -0400, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2013-08-30 09:19:42 -0400, Stephen Frost wrote:
wal_level and shared_buffers I can buy, but listen_addresses? The most
typical change there is going from localhost - '*', but you've got
* Robert Haas (robertmh...@gmail.com) wrote:
there's a fairly generous but fixed-at-startup-time limit on how many
segments you can have. In practice I don't think this matters much,
but it was a sobering reminder that the main shared memory segment,
with all of its inflexibility, has
On Fri, Aug 30, 2013 at 9:19 AM, Stephen Frost sfr...@snowman.net wrote:
You and Robert both seem to be of the opinion that this hack which
brings postgresql.conf into the database via ALTER SYSTEM is a-ok
because it's moving us forward in someone's mind, but it really is
developing a system
* Andres Freund (and...@2ndquadrant.com) wrote:
Technically trivial in the sense that it should be queryable from SQL
without having to write code in an untrusted PL ;).
hah.
I guess storing the file modification date along the file/location a GUC
is originating from would be good enough.
On Fri, Aug 30, 2013 at 9:49 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
there's a fairly generous but fixed-at-startup-time limit on how many
segments you can have. In practice I don't think this matters much,
but it was a sobering reminder that
* Robert Haas (robertmh...@gmail.com) wrote:
On Fri, Aug 30, 2013 at 8:53 AM, Stephen Frost sfr...@snowman.net wrote:
Yes, one of the issues with the existing system is that you can't
specify a default to be applied to new roles. Also, there are
parameters which are not per-role yet which
Tom, all,
I'm not one to give up a fight (I hope that's something ya'll like
about me ;), but in this case I'm gonna have to concede. Clearly, I'm
in the minority about this, at least on the lists and among the active
hackers. Let me just say that I hope all the happy users of this will
* Robert Haas (robertmh...@gmail.com) wrote:
I think you're getting way too hung up on the fact that the proposed
auto.conf will be stored as a flat file. From your comments upthread,
I gather that you'd be rejoicing if it were a table.
I'd be happy if it was a table which managed an
Stephen Frost sfr...@snowman.net writes:
* Robert Haas (robertmh...@gmail.com) wrote:
I think you're getting way too hung up on the fact that the proposed
auto.conf will be stored as a flat file. From your comments upthread,
I gather that you'd be rejoicing if it were a table.
I'd be
On Wed, Aug 28, 2013 at 3:10 PM, Stephen Frost sfr...@snowman.net wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
While I appreciate that there are bootstrap-type issues with this, I
really don't like this idea of later stuff can just override earlier
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
The sorts of watered-down half-features being proposed here are not
going to do anything to address that situation. If there are
restrictions on what GUCs can be changed with this feature, or if the
feature is disabled by default, or if
On Thu, Aug 29, 2013 at 1:42 PM, Stephen Frost sfr...@snowman.net wrote:
To be honest, I don't find the arguments of pgAdmin does it badly
nor psql users want this ability (which I find difficult to believe)
to be particularlly compelling reasons to have a dangerous
implementation (even if
On 2013-08-29 15:07:35 -0400, Robert Haas wrote:
On Thu, Aug 29, 2013 at 1:42 PM, Stephen Frost sfr...@snowman.net wrote:
To be honest, I don't find the arguments of pgAdmin does it badly
nor psql users want this ability (which I find difficult to believe)
to be particularlly compelling
On Thursday, August 29, 2013, Andres Freund wrote:
On 2013-08-29 15:07:35 -0400, Robert Haas wrote:
I don't really see a compelling reason why it can't or shouldn't be in
core. But having something better in contrib would still be an
improvement on the status quo.
I don't see much
On 2013-08-29 18:42:13 -0400, Stephen Frost wrote:
On Thursday, August 29, 2013, Andres Freund wrote:
The energy wasted in a good part of this massive 550+ messages thread is
truly saddening. We all (c|sh)ould have spent that time making PG more
awesome instead.
Perhaps not understood by
On Thursday, August 29, 2013, Andres Freund wrote:
To quote Robert two mails up:
Huh? The problem with adminpack is that it doesn't let you modify
individual configuration settings. All you can do is rewrite an
entire file.
That's clearly fixable.
I guess somebody could write a
On Thu, Aug 29, 2013 at 8:07 PM, Stephen Frost sfr...@snowman.net wrote:
Having 400 emails about it means it's contentious. That's quite different
from having a large demand. It does speak to the author's persistence as
well, but that shouldn't be a surprise.
Yet you can't ignore the fact that
Robert,
Was working on replying to this, but got distracted..
* Robert Haas (robertmh...@gmail.com) wrote:
To be honest, I think the argument that this is dangerous is pretty
ridiculous. AFAICS, the only argument anyone's advanced for this
being dangerous is the theory that you might
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, Aug 29, 2013 at 8:07 PM, Stephen Frost sfr...@snowman.net wrote:
I'm not talking about malicious DBAs but rather a generally
knowledgable DBA who changed shared_buffers up too high and then leaves on
vacation, while the OPs guys need to
On Thu, Aug 29, 2013 at 9:13 AM, Robert Haas robertmh...@gmail.com wrote:
I think the goals of this patch should be to (1) let users of other
clients manipulate the startup configuration just as easily as we can
already do using pgAdmin and (2) remove some of the concurrency
hazards that
On Tue, Aug 27, 2013 at 09:04:00AM +0530, Amit Kapila wrote:
For my part, I'd honestly rather have the first things found be what's
picked and later things be ignored. If you want it controlled by ALTER
SYSTEM, then don't set it in postgresql.conf. The problem with that is
there's no
* Bruce Momjian (br...@momjian.us) wrote:
On Tue, Aug 27, 2013 at 09:04:00AM +0530, Amit Kapila wrote:
I really hate the idea that someone could configure 'X' in
postgresql.conf and because the auto.conf line is later in the file,
it's able to override the original setting. Does not
Stephen Frost sfr...@snowman.net writes:
While I appreciate that there are bootstrap-type issues with this, I
really don't like this idea of later stuff can just override earlier
stuff.
include files and conf.d-style options are for breaking the config up,
not to allow you to override
On Wed, Aug 28, 2013 at 02:30:41PM -0400, Stephen Frost wrote:
* Bruce Momjian (br...@momjian.us) wrote:
On Tue, Aug 27, 2013 at 09:04:00AM +0530, Amit Kapila wrote:
I really hate the idea that someone could configure 'X' in
postgresql.conf and because the auto.conf line is later in the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
While I appreciate that there are bootstrap-type issues with this, I
really don't like this idea of later stuff can just override earlier
stuff.
include files and conf.d-style options are for breaking the
* Bruce Momjian (br...@momjian.us) wrote:
Agreed, but I think this is a much larger issue than ALTER SYSTEM SET.
Yeah, true.
I think changing behavior to first-seen would only add to confusion.
What we really need is a WARNING when a later postgresql.conf setting
overrides an earlier one,
On Wed, Aug 28, 2013 at 03:15:14PM -0400, Stephen Frost wrote:
* Bruce Momjian (br...@momjian.us) wrote:
Agreed, but I think this is a much larger issue than ALTER SYSTEM SET.
Yeah, true.
I think changing behavior to first-seen would only add to confusion.
What we really need is a
Stephen Frost escribió:
There are counter-examples also; sysctl.d will replace what's already
been set, so perhaps it simply depends on an individual's experience.
For my part, I'd much prefer an error or warning saying you've got
duplicate definitions of X than a last-wins approach, though
Martijn,
* Martijn van Oosterhout (klep...@svana.org) wrote:
Note, my whole purpose for suggesting something like:
include_auto_conf_filepostgresql.auto.conf
is because I want the file location to be configurable. If I put in my
configuration:
include_auto_conf_file
On Mon, Aug 26, 2013 at 10:50 PM, Stephen Frost sfr...@snowman.net wrote:
Martijn,
* Martijn van Oosterhout (klep...@svana.org) wrote:
Note, my whole purpose for suggesting something like:
include_auto_conf_filepostgresql.auto.conf
is because I want the file location to be
On Fri, Aug 23, 2013 at 06:41:04PM +0530, Amit Kapila wrote:
Not with this proposal... If it's fixed then it makes no sense to make it
look like it can be modified.
This proposal is to have a special include which user can only use
for enable/disable
which means he can remove
On Sat, Aug 24, 2013 at 6:08 PM, Martijn van Oosterhout
klep...@svana.org wrote:
On Fri, Aug 23, 2013 at 06:41:04PM +0530, Amit Kapila wrote:
Not with this proposal... If it's fixed then it makes no sense to make it
look like it can be modified.
This proposal is to have a special
* Amit Kapila (amit.kapil...@gmail.com) wrote:
On Thu, Aug 22, 2013 at 6:06 PM, Stephen Frost sfr...@snowman.net wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
Enable/Disable reading of auto file
-
a. Have a new include in
On Fri, Aug 23, 2013 at 6:01 PM, Stephen Frost sfr...@snowman.net wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
On Thu, Aug 22, 2013 at 6:06 PM, Stephen Frost sfr...@snowman.net wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
Enable/Disable reading of auto file
* Amit Kapila (amit.kapil...@gmail.com) wrote:
This can resolve the problem of whether to read auto file rather
cleanly, so the idea is:
Enable/Disable reading of auto file
-
a. Have a new include in postresql.conf
On Thu, Aug 22, 2013 at 08:36:37AM -0400, Stephen Frost wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
This can resolve the problem of whether to read auto file rather
cleanly, so the idea is:
Enable/Disable reading of auto file
On Thu, Aug 22, 2013 at 6:06 PM, Stephen Frost sfr...@snowman.net wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
This can resolve the problem of whether to read auto file rather
cleanly, so the idea is:
Enable/Disable reading of auto file
On Thu, Aug 22, 2013 at 9:34 PM, Bruce Momjian br...@momjian.us wrote:
On Thu, Aug 22, 2013 at 08:36:37AM -0400, Stephen Frost wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
This can resolve the problem of whether to read auto file rather
cleanly, so the idea is:
Enable/Disable
Martijn,
* Martijn van Oosterhout (klep...@svana.org) wrote:
ISTM you want some kind of hybrid setting like:
#include_system auto.conf
which simultaneously does three things:
1. Sets the enable_alter_system flag
2. Indicates the file to use
3. Indicates the priority of the setting re
On Wed, Aug 21, 2013 at 8:22 PM, Stephen Frost sfr...@snowman.net wrote:
Martijn,
* Martijn van Oosterhout (klep...@svana.org) wrote:
ISTM you want some kind of hybrid setting like:
#include_system auto.conf
which simultaneously does three things:
1. Sets the enable_alter_system flag
2.
* Amit Kapila (amit.kapil...@gmail.com) wrote:
Okay, let us decide how things will be if we disable by default:
1. initdb won't create any empty auto file, rather the file will be
created first time user uses ALTER SYSTEM.
I'm not particularly set on this.. Why not create the file
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Amit Kapila escribió:
3. postgresql.conf will contain include directive in below form:
#include = 'postgresql.auto.conf'
Whenever user wants to use Alter System, he needs to enable it
after first time using ALTER SYSTEM.
On Tue, Aug 20, 2013 at 6:21 PM, Stephen Frost sfr...@snowman.net wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
Okay, let us decide how things will be if we disable by default:
1. initdb won't create any empty auto file, rather the file will be
created first time user uses ALTER
* Amit Kapila (amit.kapil...@gmail.com) wrote:
On Tue, Aug 20, 2013 at 6:21 PM, Stephen Frost sfr...@snowman.net wrote:
I'm not particularly set on this.. Why not create the file initially?
If by default this feature needs to be disabled, then it is not
must to have at initdb time.
I
On Tue, Aug 20, 2013 at 6:55 PM, Stephen Frost sfr...@snowman.net wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
On Tue, Aug 20, 2013 at 6:21 PM, Stephen Frost sfr...@snowman.net wrote:
I'm not particularly set on this.. Why not create the file initially?
If by default this feature
* Amit Kapila (amit.kapil...@gmail.com) wrote:
Wouldn't it be complicated to handle this way rather then by having
include directive.
You misunderstood. I was suggesting a setup along these lines:
postgresql.conf:
# include = 'auto.conf' # Disabled by default
auto.conf:
On Tue, Aug 20, 2013 at 7:51 PM, Stephen Frost sfr...@snowman.net wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
Wouldn't it be complicated to handle this way rather then by having
include directive.
You misunderstood. I was suggesting a setup along these lines:
postgresql.conf:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
So let me try to explain what I understood from above:
1. enable_alter_system a new GUC whose default value =off.
2. Alter System will check this variable and return error (not
allowed), if this parameter is off.
3. Now if user enables include
Stephen Frost escribió:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Hopefully snippets put in conf.d/ by
puppet/chef will override the settings in postgresql.conf (i.e. conf.d/
should be processed after postgresql.conf, not before); and hopefully
ALTER SYSTEM will in turn override
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost escribió:
With includedir and include directives, and postgresql.conf setting a
defined ordering, with last-wins, you could simply have the 'includedir'
for conf.d come before the 'include' for auto.conf.
Uh, I was thinking
Stephen Frost escribió:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
So let me try to explain what I understood from above:
1. enable_alter_system a new GUC whose default value =off.
2. Alter System will check this variable and return error (not
allowed), if this parameter is off.
Stephen Frost escribió:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost escribió:
With includedir and include directives, and postgresql.conf setting a
defined ordering, with last-wins, you could simply have the 'includedir'
for conf.d come before the 'include' for
Alvaro Herrera alvhe...@2ndquadrant.com writes:
What I was proposing upthread is that enable_alter_system=off/on would
be present in postgresql.conf, and there is no include line for
auto.conf. That way, if the user wishes to enable/disable the feature,
they need to edit postgresql.conf to do
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
With this design, if you put enable_alter_system=off in auto.conf, there
is no way for the user to enable alter system again short of editing a
file in the data directory. I think this is one of the things that was
forbidden by policy; only
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost escribió:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost escribió:
With includedir and include directives, and postgresql.conf setting a
defined ordering, with last-wins, you could simply have the
Stephen Frost sfr...@snowman.net writes:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
The conf.d/ path would be relative to postgresql.conf, so there's no
need for Debian to patch anything.
Uhhh, I really don't see that working, at all...
Why not? conf.d is for installable files,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
The conf.d/ path would be relative to postgresql.conf, so there's no
need for Debian to patch anything.
Uhhh, I really don't see that working, at all...
Stephen Frost escribió:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost escribió:
I'd much rather have an includedir directive than some hard-coded or
command-line option to read the directory.. The directory should live
in /etc/postgresql/X.Y/cluster/ on at least
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost escribió:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost escribió:
I'd much rather have an includedir directive than some hard-coded or
command-line option to read the directory.. The directory
Stephen Frost escribió:
I agree that auto.conf should live in $PGDATA, but I really don't like
the idea of conf.d being relative to some other existing file. It
should be included through an 'includedir' option, not just picked up as
some magic directory name, and therefore consider the
Stephen Frost escribió:
Tried to in my other mail,
Yep, got it and replied, thanks.
but let me also point out that we
(PGDG/Upstream) don't own the directory in which postgresql.conf
lives. At least on Debian and relatives, that directory isn't under
$PGDATA and it already has other files
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Well, all the relative paths in include/includedir directives would be
relative to the directory specified by the -c config_file param, which
makes perfect sense. So the conf.d would work fine in your example.
Why would include/includedir
Stephen Frost escribió:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Well, all the relative paths in include/includedir directives would be
relative to the directory specified by the -c config_file param, which
makes perfect sense. So the conf.d would work fine in your example.
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Stephen Frost escribió:
While I really like the 'include auto.conf' style, I'm starting to think
it may not be workable after all. Another thing to consider is if the
user decides to change that include line.. What happens when the DBA
tries
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost escribió:
Of course, the current situation is quite terrible anyway, imv. Having
the GUCs be relative to whereever the user happens to run pg_ctl from is
pretty ugly- not to mention that the commented out 'defaults' won't
Stephen Frost escribió:
And what about
http://www.postgresql.org/docs/9.3/static/runtime-config-file-locations.html
... ?
When setting any of these parameters, a relative path will be
interpreted with respect to the directory in which postgres is
started.
That's talking
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost escribió:
http://www.postgresql.org/docs/9.3/static/runtime-config-file-locations.html
That's talking about the data_directory and the various foo_file
settings, though; it doesn't apply to the include settings.
Right-
On Tue, Aug 20, 2013 at 11:23:06AM -0400, Stephen Frost wrote:
What I was proposing upthread is that enable_alter_system=off/on would
be present in postgresql.conf, and there is no include line for
auto.conf.
I really think that's a terrible approach, to be honest. I want to see
an
On Tue, Aug 20, 2013 at 08:38:52AM +0530, Amit Kapila wrote:
On Tue, Aug 20, 2013 at 8:27 AM, Stephen Frost sfr...@snowman.net wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
If both are okay, then I would like to go with second option (include
file mechanism).
I think by default,
1 - 100 of 379 matches
Mail list logo
