On Tue, Nov 19, 2013 at 2:06 PM, Haribabu kommi
wrote:
> On 19 November 2013 09:59 Amit Kapila wrote:
>> On Mon, Nov 18, 2013 at 8:31 PM, Haribabu kommi
>> wrote:
>> > On 18 November 2013 20:01 Amit Kapila wrote:
>> >> > Code changes are fine.
>> >> > If two or three errors are present in the con
On 19 November 2013 09:59 Amit Kapila wrote:
> On Mon, Nov 18, 2013 at 8:31 PM, Haribabu kommi
> 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
> >> > Configura
On Mon, Nov 18, 2013 at 8:31 PM, Haribabu kommi
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 be mentioned in
On 18 November 2013 20:01 Amit Kapila wrote:
> On Mon, Nov 18, 2013 at 6:28 PM, Haribabu kommi
> 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 6:28 PM, Haribabu kommi
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,
>> >
>> (errcode(ERRCODE_CONFIG_FI
On 17 November 2013 12:25 Amit Kapila wrote:
> On Sat, Nov 16, 2013 at 4:35 PM, Haribabu kommi
> wrote:
> > On 16 November 2013 09:43 Amit Kapila wrote:
> >> On Fri, Nov 15, 2013 at 10:18 PM, Peter Eisentraut
> >> wrote:
> >> > On 11/14/13, 2:50 AM, Amit Kapila wrote:
> >> >> Find the rebased ver
On Sat, Nov 16, 2013 at 4:35 PM, Haribabu kommi
wrote:
> On 16 November 2013 09:43 Amit Kapila wrote:
>> On Fri, Nov 15, 2013 at 10:18 PM, Peter Eisentraut
>> wrote:
>> > On 11/14/13, 2:50 AM, Amit Kapila wrote:
>> >> Find the rebased version attached with this mail.
>> >
> Please find review com
On 16 November 2013 09:43 Amit Kapila wrote:
> On Fri, Nov 15, 2013 at 10:18 PM, Peter Eisentraut
> 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
On Fri, Nov 15, 2013 at 10:18 PM, Peter Eisentraut 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
> /usr/share/sgml/docbook/stylesheet/dsssl/modu
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 po
On Wed, Nov 13, 2013 at 7:23 PM, Amit Kapila wrote:
> On Wed, Nov 13, 2013 at 4:05 PM, Haribabu kommi
> wrote:
>> On 01 October 2013 00:56 Amit Kapila wrote:
>>> On Mon, Sep 30, 2013 at 9:07 PM, Peter Eisentraut
>>> wrote:
>>> > On 9/28/13 3:05 AM, Amit Kapila wrote:
>>> >> Now as we have an agr
On Wed, Nov 13, 2013 at 4:05 PM, Haribabu kommi
wrote:
> On 01 October 2013 00:56 Amit Kapila wrote:
>> On Mon, Sep 30, 2013 at 9:07 PM, Peter Eisentraut
>> 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:
>> >
>>
On 01 October 2013 00:56 Amit Kapila wrote:
> On Mon, Sep 30, 2013 at 9:07 PM, Peter Eisentraut
> 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 a
On Mon, Sep 30, 2013 at 9:07 PM, Peter Eisentraut 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 patch.
R
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:
http://www.postgresql.org/mailpref/pgsql-hac
On Fri, Aug 30, 2013 at 8:24 PM, Tom Lane wrote:
> Stephen Frost 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 r
Stephen Frost 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 happy if it was
* 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 *ind
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:
> On Fri, Aug 30, 2013 at 8:53 AM, Stephen Frost 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
On Fri, Aug 30, 2013 at 9:49 AM, Stephen Frost 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 the main shar
* 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:19 AM, Stephen Frost 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 configuration
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 yo
* 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 impo
* 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 an
On Fri, Aug 30, 2013 at 8:53 AM, Stephen Frost 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 and we'd need a w
On Thu, Aug 29, 2013 at 9:26 PM, Stephen Frost 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, now are yo
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
* 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 wh
* 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
On Thu, Aug 29, 2013 at 9:12 PM, Stephen Frost 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.
> Similairly, it'd be ni
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 tha
On 2013-08-30 08:48:21 -0400, Stephen Frost wrote:
> * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> > Stephen Frost 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
* 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 maintainin
* 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
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost 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
>
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 awesom
Stephen Frost 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 and trust problem.
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.
>
On Thu, Aug 29, 2013 at 9:13 AM, Robert Haas 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 pgAdmin introduces, for
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Aug 29, 2013 at 8:07 PM, Stephen Frost 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 do a database
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 accid
On Thu, Aug 29, 2013 at 8:07 PM, Stephen Frost 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 many people on
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 wri
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 underst
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 mu
On 2013-08-29 15:07:35 -0400, Robert Haas wrote:
> On Thu, Aug 29, 2013 at 1:42 PM, Stephen Frost 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
On Thu, Aug 29, 2013 at 1:42 PM, Stephen Frost 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 it's better th
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 Wed, Aug 28, 2013 at 3:10 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Stephen Frost 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
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, tho
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
* 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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost 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
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 la
Stephen Frost 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 options because a
* 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. Doe
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
On Mon, Aug 26, 2013 at 10:50 PM, Stephen Frost 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 configurable. If I
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/etc/
On Sat, Aug 24, 2013 at 6:08 PM, Martijn van Oosterhout
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 include which
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 remov
On Fri, Aug 23, 2013 at 6:01 PM, Stephen Frost wrote:
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
>> On Thu, Aug 22, 2013 at 6:06 PM, Stephen Frost wrote:
>> > * Amit Kapila (amit.kapil...@gmail.com) wrote:
>> >> Enable/Disable reading of auto file
>> >> -
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> On Thu, Aug 22, 2013 at 6:06 PM, Stephen Frost wrote:
> > * Amit Kapila (amit.kapil...@gmail.com) wrote:
> >> Enable/Disable reading of auto file
> >> -
> >> a. Have a new include in postresql.conf
On Thu, Aug 22, 2013 at 9:34 PM, Bruce Momjian 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 r
On Thu, Aug 22, 2013 at 6:06 PM, 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 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
> > -
* 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
> #include_a
On Wed, Aug 21, 2013 at 8:22 PM, Stephen Frost 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.
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 set
On Wed, Aug 21, 2013 at 7:29 AM, Bruce Momjian wrote:
> On Tue, Aug 20, 2013 at 08:38:52AM +0530, Amit Kapila wrote:
>> On Tue, Aug 20, 2013 at 8:27 AM, Stephen Frost wrote:
>> > * Amit Kapila (amit.kapil...@gmail.com) wrote:
>> >> If both are okay, then I would like to go with second option (inc
On Tue, Aug 20, 2013 at 10:02 PM, Alvaro Herrera
wrote:
> 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
On Tue, Aug 20, 2013 at 08:38:52AM +0530, Amit Kapila wrote:
> On Tue, Aug 20, 2013 at 8:27 AM, Stephen Frost 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, we shoul
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
* 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-
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 t
* 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
Alvaro Herrera 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 to do a 'ALTER SY
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) 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 d
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 oth
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 c
* 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
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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost 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 n
Stephen Frost 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, AIUI. What we ne
* 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
* 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; o
Alvaro Herrera 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 so. ALTER SYSTEM do
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 'inclu
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
* 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
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
* 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 inc
On Tue, Aug 20, 2013 at 7:51 PM, Stephen Frost 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:
> # include
* 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 6:55 PM, Stephen Frost wrote:
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
>> On Tue, Aug 20, 2013 at 6:21 PM, Stephen Frost wrote:
>> > I'm not particularly set on this.. Why not create the file initially?
>>If by default this feature needs to be disabled, then i
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> On Tue, Aug 20, 2013 at 6:21 PM, Stephen Frost 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 don't see how the
On Tue, Aug 20, 2013 at 6:21 PM, Stephen Frost 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 SYSTEM.
>
> I'm
1 - 100 of 382 matches
Mail list logo
