On Wed, Jan 22, 2014 at 8:56 PM, Tom Lane wrote:
> Amit Kapila writes:
>> On Tue, Jan 21, 2014 at 8:25 PM, Robert Haas wrote:
>>> While reviewing, I noted that the
>>> "skipping missing configuration file" message in ParseConfigFile()
>>> uses an elevel of LOG, while the other messages in the sa
Amit Kapila writes:
> On Tue, Jan 21, 2014 at 8:25 PM, Robert Haas wrote:
>> While reviewing, I noted that the
>> "skipping missing configuration file" message in ParseConfigFile()
>> uses an elevel of LOG, while the other messages in the same file use
>> "elevel". I'm thinking that's a bug.
>
On Tue, Jan 21, 2014 at 8:25 PM, Robert Haas wrote:
> On Fri, Jan 17, 2014 at 12:07 AM, Amit Kapila wrote:
>> On Fri, Jan 17, 2014 at 12:16 AM, Tom Lane wrote:
>>> PS: off topic, but isn't ParseConfigDirectory leaking the result
>>> of AbsoluteConfigLocation? In both normal and error paths?
>>
On Fri, Jan 17, 2014 at 12:07 AM, Amit Kapila wrote:
> On Fri, Jan 17, 2014 at 12:16 AM, Tom Lane wrote:
>> PS: off topic, but isn't ParseConfigDirectory leaking the result
>> of AbsoluteConfigLocation? In both normal and error paths?
>
>Yes, I also think it leaks in both cases and similar l
On Fri, Jan 17, 2014 at 12:16 AM, Tom Lane wrote:
> PS: off topic, but isn't ParseConfigDirectory leaking the result
> of AbsoluteConfigLocation? In both normal and error paths?
Yes, I also think it leaks in both cases and similar leak is
present in ParseConfigFile(). I have tried to fix b
On 01/16/2014 07:32 AM, Christian Kruse wrote:
> Hi Alvaro,
>
> On 16/01/14 10:21, Alvaro Herrera wrote:
>> 1. it is to be read automatically by the server without need for an
>>"include_dir conf.d" option in the main postgresql.conf.
>
> +1
>
>> 4. there is no point in "disabling" it, and t
* Josh Berkus (j...@agliodbs.com) wrote:
> On 01/16/2014 10:46 AM, Tom Lane wrote:
> > I'm fine if the proposal is that postgresql.conf include "include_dir
> > conf.d" by default (where that's read as relative to postgresql.conf's own
> > directory). Even better if it's not terribly difficult for
On 01/16/2014 10:46 AM, Tom Lane wrote:
> I'm fine if the proposal is that postgresql.conf include "include_dir
> conf.d" by default (where that's read as relative to postgresql.conf's own
> directory). Even better if it's not terribly difficult for a packager to
> change that, because I think som
Alvaro Herrera writes:
> Tom Lane wrote:
>> Another point here is that hard-wiring a config directory location
>> into the executables completely breaks many scenarios for running
>> multiple clusters with the same executables.
> Therefore the proposal is not to hardwire the location in the
> exe
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > I missed the part of this where you point out that Apache on Debian has
> > some kind of problem because it's possible for an admin to remove the
> > 'IncludeDir sites-enabled' line from apache2.conf.
>
> I don't see tha
Tom Lane wrote:
> Stephen Frost writes:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> >> 1. it is to be read automatically by the server without need for an
> >> "include_dir conf.d" option in the main postgresql.conf.
>
> > I am not thrilled with the idea that we're claiming ownership
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2014-01-16 11:35:00 -0500, Stephen Frost wrote:
> > * Andres Freund (and...@2ndquadrant.com) wrote:
> > > So, if we want to support antything but a) relative to pgdata b)
> > > relative to postgresql.conf it needs to be configurable at startup
>
On 2014-01-16 11:35:00 -0500, Stephen Frost wrote:
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > So, if we want to support antything but a) relative to pgdata b)
> > relative to postgresql.conf it needs to be configurable at startup
> > time. Possibly with an added initdb switch to set the
* Andres Freund (and...@2ndquadrant.com) wrote:
> So, if we want to support antything but a) relative to pgdata b)
> relative to postgresql.conf it needs to be configurable at startup
> time. Possibly with an added initdb switch to set the location.
How would an initdb switch be better than an opt
Avlaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Please explain. I don't see a reason not to. Are you saying you expect
> to put, say, Apache configuration files in the same directory as
> PostgreSQL's? That doesn't sound really tenable to me, and it doesn't
> sounds like what any s
On 2014-01-16 11:12:55 -0500, Tom Lane wrote:
> If we were to do this, I'd argue that the location of this hard-wired
> config directory ought to be selected by a configure option.
> in fact, I'd argue that the default behavior with no such option be
> that there's no such hard-wired directory. Th
Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > Peter Eisentraut wrote:
> > > In my mind, a conf.d directory is an extension of a single-file
> > > configuration, and so it should be handled that way.
> >
> > +1 on this. This means
> >
> > 1. it is to be read automa
Stephen Frost writes:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>> 1. it is to be read automatically by the server without need for an
>> "include_dir conf.d" option in the main postgresql.conf.
> I am not thrilled with the idea that we're claiming ownership of the
> directory which po
* Andres Freund (and...@2ndquadrant.com) wrote:
> Given that the majority didn't seem to be convinced by this and that the
> feature was written differently this isn't a convincing argument for the
> location of the file given the current feature, no?
I'll start by pointing out that the only reaso
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Peter Eisentraut wrote:
> > In my mind, a conf.d directory is an extension of a single-file
> > configuration, and so it should be handled that way.
>
> +1 on this. This means
>
> 1. it is to be read automatically by the server without need fo
Hi Alvaro,
On 16/01/14 10:21, Alvaro Herrera wrote:
> 1. it is to be read automatically by the server without need for an
>"include_dir conf.d" option in the main postgresql.conf.
+1
> 4. there is no point in "disabling" it, and thus we offer no mechanism
>to do that.
Not only there is
On 2014-01-16 08:34:23 -0500, Stephen Frost wrote:
> Peter,
>
> * Peter Eisentraut (pete...@gmx.net) wrote:
> > Then one might as well argue that the pg_db_role_setting table be
> > relocated to /etc. It's the same facility, only on a slightly different
> > level. The fact that postgresql.auto.c
Peter,
* Peter Eisentraut (pete...@gmx.net) wrote:
> Then one might as well argue that the pg_db_role_setting table be
> relocated to /etc. It's the same facility, only on a slightly different
> level. The fact that postgresql.auto.conf looks the same as a
> plain-text configuration file is an i
Peter Eisentraut wrote:
> In my mind, a conf.d directory is an extension of a single-file
> configuration, and so it should be handled that way.
+1 on this. This means
1. it is to be read automatically by the server without need for an
"include_dir conf.d" option in the main postgresql.conf.
On 1/15/14, 11:23 PM, Stephen Frost wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
>> In my mind, a conf.d directory is an extension of a single-file
>> configuration, and so it should be handled that way.
>
> I'm apparently out on some funny limb with this thought, but I'll throw
> it out t
On 01/16/2014 02:53 AM, Josh Berkus wrote:
> Hackers,
>
> ALTER SYSTEM SET has been committed and recovery.conf GUCs are being
> reviewed. I'm going to make a last case for conf.d in relation to these
> two patches before 9.4 goes out the door.
Personally, I'd find conf.d greatly more useful whe
On Thu, Jan 16, 2014 at 1:31 AM, Josh Berkus wrote:
> On 01/15/2014 11:10 AM, Stephen Frost wrote:
>
>> Independent of the above, I don't agree with that. postgresql.auto.conf
>> is a special thing and should have its own special place. For once
>> thing, when putting configuration files in a se
* Peter Eisentraut (pete...@gmx.net) wrote:
> In my mind, a conf.d directory is an extension of a single-file
> configuration, and so it should be handled that way.
I'm apparently out on some funny limb with this thought, but I'll throw
it out there anyway- in my head, the 'postgresql.auto.conf' t
On 1/15/14, 3:01 PM, Josh Berkus wrote:
> Three issues:
>
> a) if postgresql is still going to look for a recovery.conf file in the
> usual place, but we are changing the names and meaning of some of the
> parameters, then aren't we making the upgrade problem much worse?
That assumes that we are
On 1/15/14, 4:35 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 1/15/14, 1:53 PM, Josh Berkus wrote:
>>> Yes, I'm also arguing that postgresql.auto.conf should go into conf.d.
>>> I said I'd bring that up again after ALTER SYSTEM SET was committed, and
>>> here it is.
>
>> Independent of th
Peter Eisentraut writes:
> On 1/15/14, 1:53 PM, Josh Berkus wrote:
>> Yes, I'm also arguing that postgresql.auto.conf should go into conf.d.
>> I said I'd bring that up again after ALTER SYSTEM SET was committed, and
>> here it is.
> Independent of the above, I don't agree with that. postgresql.
Josh,
* Josh Berkus (j...@agliodbs.com) wrote:
> However, Debian is *never* going to add conf.d to the packages if we
> don't recommend it as an upstream project. And, frankly, I use the
> apt.postgresql.org packages anyway, which would certainly include
> anything which was decided on this list.
On 01/15/2014 11:10 AM, Stephen Frost wrote:
> I don't buy this argument one bit- certainly, on Debian, the defaults
> are overridden for a number of variables already and could be done to
> enable a conf.d directory as well. Directory creation would, of
> course, also be able to be handled by the
On 1/15/14, 1:53 PM, Josh Berkus wrote:
> I'm particularly thinking about this in relation to the merger of
> recovery.conf and postgresql.conf. There are several tools already
> (RepMgr, OminPITR, HandyRep, pgPool, etc.) which manage recovery.conf
> separately from postgresql.conf. These tools w
Josh,
* Josh Berkus (j...@agliodbs.com) wrote:
> In 9.3, we added support for a config directory (conf.d), but have it
> disabled by default. For tool authors, this makes conf.d useless since
> you never know, on any given installation, whether it will be
> present/enabled or not. While we don't
Hackers,
ALTER SYSTEM SET has been committed and recovery.conf GUCs are being
reviewed. I'm going to make a last case for conf.d in relation to these
two patches before 9.4 goes out the door.
In 9.3, we added support for a config directory (conf.d), but have it
disabled by default. For tool aut
36 matches
Mail list logo
