On Wed, Jan 21, 2015 at 11:13 AM, Sawada Masahiko wrote:
> I think this new view is updated only when postmaster received SIGHUP
> or is started.
> And we can have new function like pg_update_file_setting() which
> updates this view.
I really don't think the postmaster should be in the business o
On Wed, Jan 21, 2015 at 1:38 AM, Amit Kapila wrote:
> Now as I have suggested upthread, that we can have a new view
> pg_file_settings which will display information about settings even
> when there exists multiple entries for the same in different files.
>
> I think adding such information to exi
On Wed, Jan 21, 2015 at 1:32 AM, David Johnston
wrote:
> to make the whole thing work. Maybe it does all fit directly on pg_settings
> but tacking on some read-only columns to this updateable view/table doesn't
> come across as something that should be forbidden in general.
No, of course not. B
On Thu, Jan 22, 2015 at 11:41 AM, Amit Kapila wrote:
> On Wed, Jan 21, 2015 at 9:43 PM, Sawada Masahiko
> wrote:
>>
>> On Wed, Jan 21, 2015 at 3:38 PM, Amit Kapila
>> wrote:
>> > On Tue, Jan 20, 2015 at 9:38 PM, Robert Haas
>> > wrote:
>> >
>> >
>> > The reason why "sourcefile" and "sourceline"
On Wed, Jan 21, 2015 at 9:43 PM, Sawada Masahiko
wrote:
>
> On Wed, Jan 21, 2015 at 3:38 PM, Amit Kapila
wrote:
> > On Tue, Jan 20, 2015 at 9:38 PM, Robert Haas
wrote:
> >
> >
> > The reason why "sourcefile" and "sourceline" are not sufficient is that
> > they can only give the information about
On Wed, Jan 21, 2015 at 3:38 PM, Amit Kapila wrote:
> On Tue, Jan 20, 2015 at 9:38 PM, Robert Haas wrote:
>
> Okay and I was also not in favour of this approach.
>
Okay I agree with this.
>
> The reason why "sourcefile" and "sourceline" are not sufficient is that
> they can only give the inform
On Tue, Jan 20, 2015 at 9:38 PM, Robert Haas wrote:
>
> On Mon, Jan 19, 2015 at 10:39 PM, Amit Kapila
wrote:
> > I think whichever process reads postgresql.conf/postgresql.auto.conf
have
> > to do this (unless we restrict that this will be done at some other
time)
> > and
> > postmaster is one of
On Tue, Jan 20, 2015 at 8:46 PM, Robert Haas wrote:
> On Tue, Jan 20, 2015 at 4:07 PM, David Johnston
> wrote:
> > sourceline and sourcefile pertain only to the current value while the
> point
> > of adding these other pieces is to provide a snapshot of all the
> different
> > mappings that the
On Tue, Jan 20, 2015 at 4:07 PM, David Johnston
wrote:
> sourceline and sourcefile pertain only to the current value while the point
> of adding these other pieces is to provide a snapshot of all the different
> mappings that the system knows about; instead of having to tell a user to go
> look in
On Tue, Jan 20, 2015 at 1:24 PM, Jim Nasby wrote:
> On 1/16/15 10:32 PM, David G Johnston wrote:
> Two changes solve this problem in what seems to be a clean way.
>> 1) Upon each parsing of postgresql.conf we store all assigned variables
>> somewhere
>>
>
> Parsing is relatively cheap, and it'
On 1/16/15 10:32 PM, David G Johnston wrote:
One thought I have in this line is that currently there doesn't seem
>>>to
>>> >be
>>> >a way to know if the setting has an entry both in postgresql.conf and
>>> >postgresql.auto.conf, if we can have some way of knowing the same
>>> >(pg_settings?),
On Mon, Jan 19, 2015 at 10:39 PM, Amit Kapila wrote:
> I think whichever process reads postgresql.conf/postgresql.auto.conf have
> to do this (unless we restrict that this will be done at some other time)
> and
> postmaster is one of them. It seems to me that it is not good idea unless
> we do it
On Tue, Jan 20, 2015 at 9:09 AM, Amit Kapila
wrote:
>
>
> Right, but we can't completely eliminate such a possibility (as an
> example we have some default settings like max_connections,
> shared_buffers, etc). I agree with you that users should use only
> way
Sorry for incomplete sentence, I me
On Mon, Jan 19, 2015 at 9:35 AM, Robert Haas wrote:
>
> On Sat, Jan 17, 2015 at 12:19 AM, Amit Kapila
wrote:
> > So are you telling that whenever we read, save the settings
> > to some catalog (probably a new one)?
>
> Which process are you imagining would do this? Certainly not the
postmaster.
On Sat, Jan 17, 2015 at 12:19 AM, Amit Kapila wrote:
> So are you telling that whenever we read, save the settings
> to some catalog (probably a new one)?
Which process are you imagining would do this? Certainly not the postmaster.
Independently of that, it sounds like solving the problem from
On Sat, Jan 17, 2015 at 2:24 PM, David Johnston
wrote:
> On Fri, Jan 16, 2015 at 10:19 PM, Amit Kapila
> wrote:
>>
>> On Sat, Jan 17, 2015 at 10:41 AM, David Johnston
>> wrote:
>> > On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila
>> > wrote:
>> >>
>> >> On Sat, Jan 17, 2015 at 10:02 AM, David G J
On Fri, Jan 16, 2015 at 10:19 PM, Amit Kapila
wrote:
> On Sat, Jan 17, 2015 at 10:41 AM, David Johnston <
> david.g.johns...@gmail.com> wrote:
> > On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila
> wrote:
> >>
> >> On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston <
> david.g.johns...@gmail.com> w
On Sat, Jan 17, 2015 at 10:41 AM, David Johnston
wrote:
> On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila
wrote:
>>
>> On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston <
david.g.johns...@gmail.com> wrote:
>> > > You're right.
>> > > pg_setting and SHOW command use value in current session rather
On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila
wrote:
> On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston <
> david.g.johns...@gmail.com> wrote:
> > > You're right.
> > > pg_setting and SHOW command use value in current session rather than
> > > config file.
> > > It might break these common infr
On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston <
david.g.johns...@gmail.com> wrote:
> > You're right.
> > pg_setting and SHOW command use value in current session rather than
> > config file.
> > It might break these common infrastructure.
>
> Two changes solve this problem in what seems to be
Sawada Masahiko wrote
> On Fri, Jan 16, 2015 at 12:54 PM, Amit Kapila <
> amit.kapila16@
> > wrote:
>> On Thu, Jan 15, 2015 at 9:48 PM, Sawada Masahiko <
> sawada.mshk@
> >
>> wrote:
>>> On Thu, Jan 15, 2015 at 2:02 PM, Amit Kapila <
> amit.kapila16@
> >
>>> wrote:
>>> >
>>> > One thought I h
On Fri, Jan 16, 2015 at 9:55 PM, Sawada Masahiko
wrote:
> On Fri, Jan 16, 2015 at 12:54 PM, Amit Kapila
wrote:
> >
> > I don't know how appealing it would be to others, but a new view
> > like pg_file_settings which would display the settings in file could
> > be meaningful for your need.
> >
> >
On Fri, Jan 16, 2015 at 12:54 PM, Amit Kapila wrote:
> On Thu, Jan 15, 2015 at 9:48 PM, Sawada Masahiko
> wrote:
>> On Thu, Jan 15, 2015 at 2:02 PM, Amit Kapila
>> wrote:
>> >
>> > One thought I have in this line is that currently there doesn't seem to
>> > be
>> > a way to know if the setting h
On Thu, Jan 15, 2015 at 9:48 PM, Sawada Masahiko
wrote:
> On Thu, Jan 15, 2015 at 2:02 PM, Amit Kapila
wrote:
> >
> > One thought I have in this line is that currently there doesn't seem to
be
> > a way to know if the setting has an entry both in postgresql.conf and
> > postgresql.auto.conf, if w
On Thu, Jan 15, 2015 at 2:02 PM, Amit Kapila wrote:
> On Wed, Jan 14, 2015 at 9:01 PM, Sawada Masahiko
> wrote:
>>
>> Hi all,
>>
>> The postgresql.auto.conf is loaded after loading of postgresql.conf
>> whenever configuration file is loaded or reloaded.
>> This means that parameter in postgresql.
On Wed, Jan 14, 2015 at 9:01 PM, Sawada Masahiko
wrote:
>
> Hi all,
>
> The postgresql.auto.conf is loaded after loading of postgresql.conf
> whenever configuration file is loaded or reloaded.
> This means that parameter in postgresql.auto.conf is quite high
> priority, so the parameter in postgre
- Original Message -
> From: Sawada Masahiko
> To: Tom Lane
> Cc: PostgreSQL-development
> Sent: Wednesday, 14 January 2015, 16:09
> Subject: Re: [HACKERS] Merging postgresql.conf and postgresql.auto.conf
>
> On Thu, Jan 15, 2015 at 12:37 AM, Tom Lane wrote
On Thu, Jan 15, 2015 at 1:15 AM, Tom Lane wrote:
> Sawada Masahiko writes:
>> On Thu, Jan 15, 2015 at 12:37 AM, Tom Lane wrote:
>>> Yes. The entire reason that postgresql.auto.conf is separate is that
>>> we despaired of reading and rewriting postgresql.conf automatically
>>> without making a h
Sawada Masahiko writes:
> On Thu, Jan 15, 2015 at 12:37 AM, Tom Lane wrote:
>> Yes. The entire reason that postgresql.auto.conf is separate is that
>> we despaired of reading and rewriting postgresql.conf automatically
>> without making a hash of material in the comments. Calling the logic
>> a
On Thu, Jan 15, 2015 at 12:37 AM, Tom Lane wrote:
> Sawada Masahiko writes:
>> The postgresql.auto.conf is loaded after loading of postgresql.conf
>> whenever configuration file is loaded or reloaded.
>> This means that parameter in postgresql.auto.conf is quite high
>> priority, so the parameter
Sawada Masahiko writes:
> The postgresql.auto.conf is loaded after loading of postgresql.conf
> whenever configuration file is loaded or reloaded.
> This means that parameter in postgresql.auto.conf is quite high
> priority, so the parameter in postgresql.conf does not work at all
> even if user s
Hi all,
The postgresql.auto.conf is loaded after loading of postgresql.conf
whenever configuration file is loaded or reloaded.
This means that parameter in postgresql.auto.conf is quite high
priority, so the parameter in postgresql.conf does not work at all
even if user set it manually.
If user w
32 matches
Mail list logo
