On Tue, Aug 12, 2014 at 1:23 PM, Amit Kapila wrote:
> On Mon, Aug 11, 2014 at 11:08 PM, Fujii Masao wrote:
>>
>>
>> While updating the patch, I found that the ConfigVariable which
>> is removed from list has the fields that the memory has been already
>> allocated but we forgot to free them. So I
On Mon, Aug 11, 2014 at 11:08 PM, Fujii Masao wrote:
>
>
> While updating the patch, I found that the ConfigVariable which
> is removed from list has the fields that the memory has been already
> allocated but we forgot to free them. So I included the code to free
> them in the patch.
Yes, that i
On Sun, Aug 10, 2014 at 3:54 PM, Amit Kapila wrote:
> On Fri, Aug 8, 2014 at 11:41 AM, Fujii Masao wrote:
>>
>> Yep, right. ParseConfigFp() is not good place to pick up data_directory.
>> What about the attached patch which makes ProcessConfigFile() instead of
>> ParseConfigFp() pick up data_dire
On Sun, Aug 10, 2014 at 12:24 PM, Amit Kapila
wrote:
>
> On Fri, Aug 8, 2014 at 11:41 AM, Fujii Masao
wrote:
> >
> > Yep, right. ParseConfigFp() is not good place to pick up data_directory.
> > What about the attached patch which makes ProcessConfigFile() instead of
> > ParseConfigFp() pick up da
On Fri, Aug 8, 2014 at 11:41 AM, Fujii Masao wrote:
>
> Yep, right. ParseConfigFp() is not good place to pick up data_directory.
> What about the attached patch which makes ProcessConfigFile() instead of
> ParseConfigFp() pick up data_directory just after the configuration file
is
> parsed?
I thi
On Fri, Aug 8, 2014 at 1:19 PM, Amit Kapila wrote:
> On Thu, Aug 7, 2014 at 12:36 PM, Fujii Masao wrote:
>> On Thu, Aug 7, 2014 at 12:36 PM, Amit Kapila
>> wrote:
>> > On Wed, Aug 6, 2014 at 1:32 PM, Fujii Masao
>> > wrote:
>
>> >> What about picking up only data_directory at the first pass?
>>
On Thu, Aug 7, 2014 at 12:36 PM, Fujii Masao wrote:
> On Thu, Aug 7, 2014 at 12:36 PM, Amit Kapila
wrote:
> > On Wed, Aug 6, 2014 at 1:32 PM, Fujii Masao
wrote:
> >> What about picking up only data_directory at the first pass?
> >
> > I think that will workout and for that I think we might need
On Thu, Aug 7, 2014 at 12:28 PM, Amit Kapila wrote:
> On Wed, Aug 6, 2014 at 11:39 AM, Fujii Masao wrote:
>>
>> On Tue, Aug 5, 2014 at 12:49 PM, Fujii Masao
>> wrote:
>> > On Mon, Aug 4, 2014 at 11:52 PM, Tom Lane wrote:
>> >> Fujii Masao writes:
>> >>> The patch chooses the last settings for
On Thu, Aug 7, 2014 at 12:36 PM, Amit Kapila wrote:
> On Wed, Aug 6, 2014 at 1:32 PM, Fujii Masao wrote:
>> On Tue, Jul 29, 2014 at 9:26 PM, Amit Kapila
>> wrote:
>> >
>> > The reason is that during startup DataDir is not set by the time server
>> > processes config file due to which we process
On Wed, Aug 6, 2014 at 1:32 PM, Fujii Masao wrote:
> On Tue, Jul 29, 2014 at 9:26 PM, Amit Kapila
wrote:
> >
> > The reason is that during startup DataDir is not set by the time server
> > processes config file due to which we process .auto.conf file in second
> > pass. I think ideally it should
On Wed, Aug 6, 2014 at 11:39 AM, Fujii Masao wrote:
>
> On Tue, Aug 5, 2014 at 12:49 PM, Fujii Masao
wrote:
> > On Mon, Aug 4, 2014 at 11:52 PM, Tom Lane wrote:
> >> Fujii Masao writes:
> >>> The patch chooses the last settings for every parameters and ignores
the
> >>> former settings. But I d
On Tue, Jul 29, 2014 at 9:26 PM, Amit Kapila wrote:
> On Mon, Jul 28, 2014 at 11:33 PM, Fujii Masao wrote:
>> There is other side effect on this patch. With the patch, when reloading
>> the configurartion file, the server cannot warm an invalid setting value
>> if it's not the last setting of the
On Tue, Aug 5, 2014 at 12:49 PM, Fujii Masao wrote:
> On Mon, Aug 4, 2014 at 11:52 PM, Tom Lane wrote:
>> Fujii Masao writes:
>>> The patch chooses the last settings for every parameters and ignores the
>>> former settings. But I don't think that every parameters need to be
>>> processed
>>> th
On Mon, Aug 4, 2014 at 11:52 PM, Tom Lane wrote:
> Fujii Masao writes:
>> The patch chooses the last settings for every parameters and ignores the
>> former settings. But I don't think that every parameters need to be processed
>> this way. That is, we can change the patch so that only PGC_POSTMA
On Tue, Jul 29, 2014 at 3:33 AM, Josh Berkus wrote:
> On 07/28/2014 11:03 AM, Fujii Masao wrote:
>> On Sat, Jul 26, 2014 at 1:07 PM, Amit Kapila wrote:
>>> On Fri, Jul 25, 2014 at 6:11 PM, Fujii Masao wrote:
On Wed, Jul 9, 2014 at 11:05 PM, Amit Kapila
wrote:
> Okay. As mentioned
Fujii Masao writes:
> The patch chooses the last settings for every parameters and ignores the
> former settings. But I don't think that every parameters need to be processed
> this way. That is, we can change the patch so that only PGC_POSTMASTER
> parameters are processed that way. The invalid s
On Mon, Jul 28, 2014 at 11:33 PM, Fujii Masao wrote:
> There is other side effect on this patch. With the patch, when reloading
> the configurartion file, the server cannot warm an invalid setting value
> if it's not the last setting of the parameter. This may cause problematic
> situation as foll
On 07/28/2014 11:03 AM, Fujii Masao wrote:
> On Sat, Jul 26, 2014 at 1:07 PM, Amit Kapila wrote:
>> On Fri, Jul 25, 2014 at 6:11 PM, Fujii Masao wrote:
>>> On Wed, Jul 9, 2014 at 11:05 PM, Amit Kapila
>>> wrote:
Okay. As mentioned upthread, I have fixed by ensuring that for duplicate
c
On Sat, Jul 26, 2014 at 1:07 PM, Amit Kapila wrote:
> On Fri, Jul 25, 2014 at 6:11 PM, Fujii Masao wrote:
>> On Wed, Jul 9, 2014 at 11:05 PM, Amit Kapila
>> wrote:
>> > Okay. As mentioned upthread, I have fixed by ensuring that for duplicate
>> > config params, retain only which comes later duri
On Fri, Jul 25, 2014 at 6:11 PM, Fujii Masao wrote:
> On Wed, Jul 9, 2014 at 11:05 PM, Amit Kapila
wrote:
> > Okay. As mentioned upthread, I have fixed by ensuring that for duplicate
> > config params, retain only which comes later during parsing.
> > I think it might have been bit simpler to fix
On Wed, Jul 9, 2014 at 11:05 PM, Amit Kapila wrote:
> On Wed, Jul 9, 2014 at 10:14 AM, Tom Lane wrote:
>>
>> Amit Kapila writes:
>> > On Wed, Jul 9, 2014 at 6:40 AM, Mark Kirkwood
>> >
>> > wrote:
>> >> Yes, but even well behaved users will see this type of error, because
>> >> initdb uncomment
On Wed, Jul 23, 2014 at 11:02 PM, Alvaro Herrera
wrote:
> Tom Lane wrote:
> > Alvaro Herrera writes:
> > > Tom Lane wrote:
> > >> No, ALTER SYSTEM is there now and it needs to work right in its first
> > >> release. I will go fix this if nobody else does.
> >
> > > Just checking -- you didn't ge
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> No, ALTER SYSTEM is there now and it needs to work right in its first
> >> release. I will go fix this if nobody else does.
>
> > Just checking -- you didn't get around to dealing with this, right?
>
> Not yet... do you want it?
Alvaro Herrera writes:
> Tom Lane wrote:
>> No, ALTER SYSTEM is there now and it needs to work right in its first
>> release. I will go fix this if nobody else does.
> Just checking -- you didn't get around to dealing with this, right?
Not yet... do you want it?
regards
Tom Lane wrote:
> Josh Berkus writes:
> >> 2. *Then*, in a second pass, enforce requirements like "can't be
> >> changed except at server start".
>
> > This would also make conf.d much more useful; I wouldn't have to worry
> > as much about overlapping config settings.
>
> > Sounds like a 9.5 f
Josh Berkus writes:
> On 07/08/2014 10:07 AM, Robert Haas wrote:
>> I haven't looked at the code in this area too carefully, but it seems
>> to me like the flow ought to be:
>>
>> 1. Read all of the config files and determine what the final value
>> present in each config file is.
AFAICS we only
On 07/08/2014 06:10 PM, Mark Kirkwood wrote:
> On 09/07/14 05:13, Josh Berkus wrote:
>> On 07/06/2014 01:27 AM, Christoph Berg wrote:
>>> Another could be that during initdb all the uncommented settings be
written to postgresql.auto.conf file rather than to postgresql.conf.
I think we can
On 07/08/2014 08:18 PM, Amit Kapila wrote:
>> Yes, but even well behaved users will see this type of error, because
> initdb uncomments certain values (ones that are dead certs for being
> changed via ALTER SYSTEM subsequently like shared_buffers), and then -
> bang! your next reload gets that "you
Re: Tom Lane 2014-07-08 <28635.1404844...@sss.pgh.pa.us>
> > Sounds like a 9.5 feature, though.
>
> No, ALTER SYSTEM is there now and it needs to work right in its first
> release. I will go fix this if nobody else does.
I'd like to throw in again that imho this should include ALTER SYSTEM
RESET
On Wed, Jul 9, 2014 at 10:14 AM, Tom Lane wrote:
>
> Amit Kapila writes:
> > On Wed, Jul 9, 2014 at 6:40 AM, Mark Kirkwood <
mark.kirkw...@catalyst.net.nz>
> > wrote:
> >> Yes, but even well behaved users will see this type of error, because
> >> initdb uncomments certain values (ones that are de
Amit Kapila writes:
> On Wed, Jul 9, 2014 at 6:40 AM, Mark Kirkwood
> wrote:
>> Yes, but even well behaved users will see this type of error, because
>> initdb uncomments certain values (ones that are dead certs for being
>> changed via ALTER SYSTEM subsequently like shared_buffers), and then -
>
On Wed, Jul 9, 2014 at 6:40 AM, Mark Kirkwood
wrote:
> On 09/07/14 05:13, Josh Berkus wrote:
>>> Another could be that during initdb all the uncommented settings be
written to postgresql.auto.conf file rather than to postgresql.conf.
I think we can do this by changing code in initdb
On Tue, Jul 8, 2014 at 11:59 PM, Tom Lane wrote:
>
> No, ALTER SYSTEM is there now and it needs to work right in its first
> release. I will go fix this if nobody else does.
I am planing to provide an initial patch for this issue in a day or so, hope
that is not too late.
With Regards,
Amit Kap
On 09/07/14 05:13, Josh Berkus wrote:
On 07/06/2014 01:27 AM, Christoph Berg wrote:
Another could be that during initdb all the uncommented settings be
written to postgresql.auto.conf file rather than to postgresql.conf.
I think we can do this by changing code in initdb.c->setup_config().
This
On 07/06/2014 01:27 AM, Christoph Berg wrote:
> Another could be that during initdb all the uncommented settings be
>> written to postgresql.auto.conf file rather than to postgresql.conf.
>> I think we can do this by changing code in initdb.c->setup_config().
>> This will ensure that unless user is
On 07/08/2014 10:07 AM, Robert Haas wrote:
> I haven't looked at the code in this area too carefully, but it seems
> to me like the flow ought to be:
>
> 1. Read all of the config files and determine what the final value
> present in each config file is.
> 2. *Then*, in a second pass, enforce requ
On Sat, Jul 5, 2014 at 10:52 AM, Tom Lane wrote:
> Amit Kapila writes:
>> Please find the patch attached to address the above concern. I have
>> updated docs, so that users can be aware of such behaviour.
>
> I'm in the camp that says that we need to do something about this, not
> just claim tha
On Sun, Jul 6, 2014 at 1:57 PM, Christoph Berg wrote:
> Re: Amit Kapila 2014-07-06
> > Another could be that during initdb all the uncommented settings be
> > written to postgresql.auto.conf file rather than to postgresql.conf.
> > I think we can do this by changing code in initdb.c->setup_config
Re: Amit Kapila 2014-07-06
> Another could be that during initdb all the uncommented settings be
> written to postgresql.auto.conf file rather than to postgresql.conf.
> I think we can do this by changing code in initdb.c->setup_config().
> This will ensure that unless user is changing settings i
On Sat, Jul 5, 2014 at 8:22 PM, Tom Lane wrote:
>
> Amit Kapila writes:
> > Please find the patch attached to address the above concern. I have
> > updated docs, so that users can be aware of such behaviour.
>
> I'm in the camp that says that we need to do something about this, not
> just claim
Amit Kapila writes:
> Please find the patch attached to address the above concern. I have
> updated docs, so that users can be aware of such behaviour.
I'm in the camp that says that we need to do something about this, not
just claim that it's operating as designed. AFAICS, the *entire* argumen
On Fri, Jun 27, 2014 at 9:11 AM, Amit Kapila
wrote:
> On Thu, Jun 26, 2014 at 1:49 PM, Christoph Berg wrote:
> > Re: Amit Kapila 2014-06-26
> > >
> > > How about adding a note in Alter System so that users are aware of
> > > such behaviour and can ensure that they don't have duplicate entries?
>
On Thu, Jun 26, 2014 at 1:49 PM, Christoph Berg wrote:
>
> Re: Amit Kapila 2014-06-26
> > On Wed, Jun 25, 2014 at 7:52 PM, Christoph Berg wrote:
> > > Re: Amit Kapila 2014-06-25 <
> > caa4ek1+f9ztogvvw-wyj2+vt0k8_jxtziqhp8ivb7wdo1w1...@mail.gmail.com>
> > >
> > > > I think maintaining values bot
Re: Amit Kapila 2014-06-26
> On Wed, Jun 25, 2014 at 7:52 PM, Christoph Berg wrote:
> > Re: Amit Kapila 2014-06-25 <
> caa4ek1+f9ztogvvw-wyj2+vt0k8_jxtziqhp8ivb7wdo1w1...@mail.gmail.com>
> >
> > > I think maintaining values both in postgresql.conf and by Alter System
> > > is not advisable.
> >
On Wed, Jun 25, 2014 at 7:52 PM, Christoph Berg wrote:
> Re: Amit Kapila 2014-06-25 <
caa4ek1+f9ztogvvw-wyj2+vt0k8_jxtziqhp8ivb7wdo1w1...@mail.gmail.com>
>
> > I think maintaining values both in postgresql.conf and by Alter System
> > is not advisable.
>
> Possibly, but then the system should be w
Re: Amit Kapila 2014-06-25
> The main reason behind such such a behaviour after restart is
> that there are duplicate entries, one in postgresql.conf and
> another in postgresql.conf. It always first read postgresql.conf
> and then .auto file and applies the changed parameters one by one,
> so w
On Wed, Jun 25, 2014 at 7:45 PM, Amit Kapila
wrote:
>
> On Wed, Jun 25, 2014 at 6:47 PM, Christoph Berg wrote:
> > Re: Amit Kapila 2014-06-25 <
caa4ek1log98jvfov9wztqpcdewja+5jr54ttpkiz3xbngjy...@mail.gmail.com>
> > > This will happen without Alter System as well, if you change
> > > the value of
On Wed, Jun 25, 2014 at 6:47 PM, Christoph Berg wrote:
> Re: Amit Kapila 2014-06-25 <
caa4ek1log98jvfov9wztqpcdewja+5jr54ttpkiz3xbngjy...@mail.gmail.com>
> > This will happen without Alter System as well, if you change
> > the value of port in postgresql.conf and try to load conf file with
SIGHUP.
Re: Amit Kapila 2014-06-25
> On Wed, Jun 25, 2014 at 6:11 PM, Christoph Berg wrote:
> >
> > I've just run into this:
> >
> > $ psql -p 5433 (that port is configured in postgresql.conf)
> > # alter system set port = 5494;
> >
> > ... restart the server
> >
> > $ psql -p 5494
> > # select pg_rel
Hi,
On Wed, 2014-06-25 at 18:42 +0530, Amit Kapila wrote:
> This will happen without Alter System as well, if you change
> the value of port in postgresql.conf and try to load conf file with
> SIGHUP. You cannot reload PGC_POSTMASTER parameters without server
> restart.
Ok, but Christoph already
On Wed, Jun 25, 2014 at 6:11 PM, Christoph Berg wrote:
>
> I've just run into this:
>
> $ psql -p 5433 (that port is configured in postgresql.conf)
> # alter system set port = 5494;
>
> ... restart the server
>
> $ psql -p 5494
> # select pg_reload_conf();
>
> 2014-06-25 14:22:07 CEST [11297-4]
I've just run into this:
$ psql -p 5433 (that port is configured in postgresql.conf)
# alter system set port = 5494;
... restart the server
$ psql -p 5494
# select pg_reload_conf();
2014-06-25 14:22:07 CEST [11297-4] LOG: received SIGHUP, reloading
configuration files
2014-06-25 14:22:07 CE
52 matches
Mail list logo
