On Thu, Jun 19, 2014 at 5:21 PM, Fujii Masao wrote:
>
> On Wed, Jun 18, 2014 at 1:07 PM, Abhijit Menon-Sen
wrote:
> > At 2014-06-18 12:55:36 +0900, masao.fu...@gmail.com wrote:
> >>
> >> Also I'm thinking to backpatch this to 9.4 because this is a bugfix
> >> rather than new feature.
> >
> > That
On Wed, Jun 18, 2014 at 1:07 PM, Abhijit Menon-Sen wrote:
> At 2014-06-18 12:55:36 +0900, masao.fu...@gmail.com wrote:
>>
>> Also I'm thinking to backpatch this to 9.4 because this is a bugfix
>> rather than new feature.
>
> That sounds reasonable, thanks.
Committed!
Regards,
--
Fujii Masao
At 2014-06-18 12:55:36 +0900, masao.fu...@gmail.com wrote:
>
> Also I'm thinking to backpatch this to 9.4 because this is a bugfix
> rather than new feature.
That sounds reasonable, thanks.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Tue, Jun 17, 2014 at 2:08 PM, Abhijit Menon-Sen wrote:
> At 2014-06-17 09:49:35 +0530, amit.kapil...@gmail.com wrote:
>>
>> By above do you mean that the patch should allow GUC_NOT_IN_SAMPLE or
>> something else, if earlier then I have removed it as per comment from
>> Fujji-san.
>
> Yes, what
At 2014-06-17 09:49:35 +0530, amit.kapil...@gmail.com wrote:
>
> By above do you mean that the patch should allow GUC_NOT_IN_SAMPLE or
> something else, if earlier then I have removed it as per comment from
> Fujji-san.
Yes, what you've done in v3 of the patch is what I meant. I've marked
this as
On Mon, Jun 16, 2014 at 7:06 PM, Fujii Masao wrote:
> > Developer options are mainly for debugging information or might help in
one
> > of the situations, so I thought somebody might not want them to be part
of
> > server configuration once they are set. We already disallow parameters
like
> > co
On Mon, Jun 16, 2014 at 12:14 PM, Amit Kapila wrote:
> On Sun, Jun 15, 2014 at 6:29 PM, Christoph Berg wrote:
>>
>> Re: Amit Kapila 2014-06-13
>>
>> > Agreed, I had mentioned in Notes section of document. Apart from that
>> > I had disallowed parameters that are excluded from postgresql.conf by
Re: Amit Kapila 2014-06-16
> Developer options are mainly for debugging information or might help in one
> of the situations, so I thought somebody might not want them to be part of
> server configuration once they are set. We already disallow parameters like
> config_file, transaction_isolation
On Sun, Jun 15, 2014 at 6:29 PM, Christoph Berg wrote:
>
> Re: Amit Kapila 2014-06-13
> > Agreed, I had mentioned in Notes section of document. Apart from that
> > I had disallowed parameters that are excluded from postgresql.conf by
> > initdb (Developer options) and they are recommended in use
Re: Amit Kapila 2014-06-13
> Agreed, I had mentioned in Notes section of document. Apart from that
> I had disallowed parameters that are excluded from postgresql.conf by
> initdb (Developer options) and they are recommended in user manual
> to be not used in production.
Excluding developer opt
On Thu, Jun 12, 2014 at 7:26 PM, Fujii Masao wrote:
>
> On Tue, May 27, 2014 at 2:05 PM, Amit Kapila
wrote:
> > On Sun, May 11, 2014 at 11:23 PM, Tom Lane wrote:
> >> I think it's clearly *necessary* to forbid setting data_directory in
> >> postgresql.auto.conf. The file is defined to be found
On Tue, May 27, 2014 at 2:05 PM, Amit Kapila wrote:
> On Sun, May 11, 2014 at 11:23 PM, Tom Lane wrote:
>> I think it's clearly *necessary* to forbid setting data_directory in
>> postgresql.auto.conf. The file is defined to be found in the data
>> directory, so any such setting is circular logic
On Tue, May 27, 2014 at 10:35 AM, Amit Kapila
wrote:
> On Sun, May 11, 2014 at 11:23 PM, Tom Lane wrote:
> > I think it's clearly *necessary* to forbid setting data_directory in
> > postgresql.auto.conf. The file is defined to be found in the data
> > directory, so any such setting is circular l
On Sun, May 11, 2014 at 11:23 PM, Tom Lane wrote:
> I think it's clearly *necessary* to forbid setting data_directory in
> postgresql.auto.conf. The file is defined to be found in the data
> directory, so any such setting is circular logic by definition;
> no good can come of not rejecting it.
>
On Mon, May 12, 2014 at 12:50 AM, Tom Lane wrote:
> Since this bug would block testing of ALTER SYSTEM by a nontrivial
> population of users, I felt it was important to get it fixed before beta,
> so I went to try and fix it as above. It turns out that reading the two
> config files separately do
On Sun, May 11, 2014 at 3:20 PM, Tom Lane wrote:
> I wrote:
>> I think what probably has to happen is that ProcessConfigFile shouldn't
>> be internally responsible for reading the auto file at all, but that we
>> do that via two separate calls to ProcessConfigFile, one for the main
>> file and the
I wrote:
> I think what probably has to happen is that ProcessConfigFile shouldn't
> be internally responsible for reading the auto file at all, but that we
> do that via two separate calls to ProcessConfigFile, one for the main
> file and then one for the auto file; and during initial startup,
> S
Amit Kapila writes:
> This problem occurs because we don't have the value of data_directory
> set in postgresql.conf by the time we want to parse .auto.conf file
> during server start. The value of data_directory is only available after
> processing of config files. To fix it, we need to store t
Amit Kapila writes:
> In above scenario, I think you are expecting it should use
> /data2/postgresql.auto.conf and that is what you have mentioned
> up-thread. The way to handle it by server is just to forbid setting
> this parameter
> by Alter System or the user himself should not perform such a
On Sun, May 11, 2014 at 4:38 AM, Fujii Masao wrote:
> ISTM that data_directory is in different situation from the other. That is,
> setting data_directory in postgresql.auto.conf is problematic whether its
> setting value is valid or invalid. Imagine the case where data_directory
> is set to '/dat
On Sat, May 10, 2014 at 12:30 PM, Amit Kapila wrote:
> On Fri, May 9, 2014 at 7:01 PM, Fujii Masao wrote:
>> On Fri, May 9, 2014 at 1:06 PM, Amit Kapila wrote:
>>> There is no harm in forbidding data_directory, but similarly we can
>>> imagine that people can set some very large values for some
On Fri, May 9, 2014 at 7:01 PM, Fujii Masao wrote:
> On Fri, May 9, 2014 at 1:06 PM, Amit Kapila wrote:
>> There is no harm in forbidding data_directory, but similarly we can
>> imagine that people can set some very large values for some config
>> variables due to which later it can have symptoms
On Fri, May 9, 2014 at 1:06 PM, Amit Kapila wrote:
> On Thu, May 8, 2014 at 9:47 PM, Christoph Berg wrote:
>> Re: Andres Freund 2014-05-08 <20140508145901.gb1...@awork2.anarazel.de>
>>> > Maybe this is nitpicking, but what happens when postgresql.auto.conf also
>>> > includes the setting of data_
On Thu, May 8, 2014 at 9:47 PM, Christoph Berg wrote:
> Re: Andres Freund 2014-05-08 <20140508145901.gb1...@awork2.anarazel.de>
>> > Maybe this is nitpicking, but what happens when postgresql.auto.conf also
>> > includes the setting of data_directory? This is possible because we can
>> > set data_
Re: Andres Freund 2014-05-08 <20140508145901.gb1...@awork2.anarazel.de>
> > Maybe this is nitpicking, but what happens when postgresql.auto.conf also
> > includes the setting of data_directory? This is possible because we can
> > set data_directory via ALTER SYSTEM now. Should we just ignore such
>
On 2014-05-08 22:21:43 +0900, Fujii Masao wrote:
> On Wed, May 7, 2014 at 4:57 PM, Amit Kapila wrote:
> > On Tue, May 6, 2014 at 7:04 PM, Christoph Berg wrote:
> >> Hi,
> >>
> >> if you split configuration and data by setting data_directory,
> >> postgresql.auto.conf is writen to the data directo
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> On Thu, May 8, 2014 at 6:51 PM, Fujii Masao wrote:
> > Should we just ignore such
> > problematic setting in postgresql.auto.conf with warning message?
>
> Another way could be that we detect the same during server start
> (while parsing postgresql
On Thu, May 8, 2014 at 6:51 PM, Fujii Masao wrote:
> On Wed, May 7, 2014 at 4:57 PM, Amit Kapila wrote:
>> This problem occurs because we don't have the value of data_directory
>> set in postgresql.conf by the time we want to parse .auto.conf file
>> during server start. The value of data_direct
On Wed, May 7, 2014 at 4:57 PM, Amit Kapila wrote:
> On Tue, May 6, 2014 at 7:04 PM, Christoph Berg wrote:
>> Hi,
>>
>> if you split configuration and data by setting data_directory,
>> postgresql.auto.conf is writen to the data directory
>> (/var/lib/postgresql/9.4/main in Debian), but tried to
Re: Amit Kapila 2014-05-07
> This problem occurs because we don't have the value of data_directory
> set in postgresql.conf by the time we want to parse .auto.conf file
> during server start. The value of data_directory is only available after
> processing of config files. To fix it, we need to
On Tue, May 6, 2014 at 7:04 PM, Christoph Berg wrote:
> Hi,
>
> if you split configuration and data by setting data_directory,
> postgresql.auto.conf is writen to the data directory
> (/var/lib/postgresql/9.4/main in Debian), but tried to be read from
> the etc directory (/etc/postgresql/9.4/main)
On Tue, May 6, 2014 at 7:04 PM, Christoph Berg wrote:
> Hi,
>
> if you split configuration and data by setting data_directory,
> postgresql.auto.conf is writen to the data directory
> (/var/lib/postgresql/9.4/main in Debian), but tried to be read from
> the etc directory (/etc/postgresql/9.4/main)
Hi,
if you split configuration and data by setting data_directory,
postgresql.auto.conf is writen to the data directory
(/var/lib/postgresql/9.4/main in Debian), but tried to be read from
the etc directory (/etc/postgresql/9.4/main).
One place to fix it would be in ProcessConfigFile in
src/backen
33 matches
Mail list logo
