On Thu, Jan 9, 2014 at 11:06 PM, Amit Kapila wrote:
> On Thu, Jan 9, 2014 at 12:26 AM, Robert Haas wrote:
>> On Mon, Jan 6, 2014 at 11:37 PM, Amit Kapila wrote:
>>> On Tue, Jan 7, 2014 at 12:52 AM, Robert Haas wrote:
On Mon, Jan 6, 2014 at 9:48 AM, Amit Kapila
wrote:
>> Couldn't
On Thu, Jan 9, 2014 at 12:26 AM, Robert Haas wrote:
> On Mon, Jan 6, 2014 at 11:37 PM, Amit Kapila wrote:
>> On Tue, Jan 7, 2014 at 12:52 AM, Robert Haas wrote:
>>> On Mon, Jan 6, 2014 at 9:48 AM, Amit Kapila wrote:
> Couldn't we also handle this by postponing FreeConfigVariables until
On Mon, Jan 6, 2014 at 11:37 PM, Amit Kapila wrote:
> On Tue, Jan 7, 2014 at 12:52 AM, Robert Haas wrote:
>> On Mon, Jan 6, 2014 at 9:48 AM, Amit Kapila wrote:
Couldn't we also handle this by postponing FreeConfigVariables until
after the if (error) block?
>>>
>>>Wouldn't doing tha
On Tue, Jan 7, 2014 at 12:52 AM, Robert Haas wrote:
> On Mon, Jan 6, 2014 at 9:48 AM, Amit Kapila wrote:
>>> Couldn't we also handle this by postponing FreeConfigVariables until
>>> after the if (error) block?
>>
>>Wouldn't doing that way can lead to bigger memory leak, if error level
>>i
On Mon, Jan 6, 2014 at 9:48 AM, Amit Kapila wrote:
>> Couldn't we also handle this by postponing FreeConfigVariables until
>> after the if (error) block?
>
>Wouldn't doing that way can lead to bigger memory leak, if error level
>is ERROR. Though in current fix also it can leak memory but i
On Mon, Jan 6, 2014 at 7:58 PM, Robert Haas wrote:
> On Sun, Dec 22, 2013 at 10:02 AM, Amit Kapila wrote:
>> On Sun, Dec 22, 2013 at 3:01 PM, Fujii Masao wrote:
>>> I found the bug of ALTER SYSTEM SET patch. The procedure to reproduce
>>> it is here.
>>>
FreeConfigVariables(head);
On Sun, Dec 22, 2013 at 10:02 AM, Amit Kapila wrote:
> On Sun, Dec 22, 2013 at 3:01 PM, Fujii Masao wrote:
>> I found the bug of ALTER SYSTEM SET patch. The procedure to reproduce
>> it is here.
>>
>> $ psql
>> =# ALTER SYSTEM SET shared_buffers = '512MB';
>> ALTER SYSTEM
>> =# \q
>> $ pg_ctl -D
On Fri, Dec 27, 2013 at 5:01 AM, Robert Haas wrote:
> On Tue, Dec 24, 2013 at 10:08 AM, Fujii Masao wrote:
>> When I read ProcessConfigFile() more carefully, I found another related
>> problem. The procedure to reproduce the problem is here.
>>
>>
>> $ psql
>> =# ALTER SYSTEM
On Tue, Dec 24, 2013 at 11:38 PM, Fujii Masao wrote:
>> On Sun, Dec 22, 2013 at 8:32 PM, Amit Kapila wrote:
>>> On Sun, Dec 22, 2013 at 3:01 PM, Fujii Masao wrote:
I found the bug of ALTER SYSTEM SET patch. The procedure to reproduce
it is here.
$ psql
=# ALTER SYSTEM SE
On Tue, Dec 24, 2013 at 10:08 AM, Fujii Masao wrote:
> On Tue, Dec 24, 2013 at 2:57 AM, Amit Kapila wrote:
>> On Sun, Dec 22, 2013 at 8:32 PM, Amit Kapila wrote:
>>> On Sun, Dec 22, 2013 at 3:01 PM, Fujii Masao wrote:
I found the bug of ALTER SYSTEM SET patch. The procedure to reproduce
>>
On Tue, Dec 24, 2013 at 2:57 AM, Amit Kapila wrote:
> On Sun, Dec 22, 2013 at 8:32 PM, Amit Kapila wrote:
>> On Sun, Dec 22, 2013 at 3:01 PM, Fujii Masao wrote:
>>> I found the bug of ALTER SYSTEM SET patch. The procedure to reproduce
>>> it is here.
>>>
>>> $ psql
>>> =# ALTER SYSTEM SET shared
On 23 December 2013 19:35, Robert Haas wrote:
> On Mon, Dec 23, 2013 at 2:19 PM, Thom Brown wrote:
>>> I would think that you'd need to have auto_explain loaded in the
>>> backend where you're trying to make a change, but you shouldn't need
>>> the setting to be present in postgresql.conf, I woul
On Mon, Dec 23, 2013 at 2:19 PM, Thom Brown wrote:
>> I would think that you'd need to have auto_explain loaded in the
>> backend where you're trying to make a change, but you shouldn't need
>> the setting to be present in postgresql.conf, I would think.
>
> This appears to be the case. I hadn't
On 23 December 2013 19:14, Robert Haas wrote:
> On Mon, Dec 23, 2013 at 1:42 PM, Thom Brown wrote:
>> Discussion around this topic has reached hundreds of messages, and
>> whilst I have failed to find mention of my following question, I
>> appreciate it may have already been discussed.
>>
>> I ha
On Mon, Dec 23, 2013 at 1:42 PM, Thom Brown wrote:
> Discussion around this topic has reached hundreds of messages, and
> whilst I have failed to find mention of my following question, I
> appreciate it may have already been discussed.
>
> I have noticed that configuration parameters for extension
Discussion around this topic has reached hundreds of messages, and
whilst I have failed to find mention of my following question, I
appreciate it may have already been discussed.
I have noticed that configuration parameters for extensions are only
supported if the server was started with one of th
On Sun, Dec 22, 2013 at 8:32 PM, Amit Kapila wrote:
> On Sun, Dec 22, 2013 at 3:01 PM, Fujii Masao wrote:
>> I found the bug of ALTER SYSTEM SET patch. The procedure to reproduce
>> it is here.
>>
>> $ psql
>> =# ALTER SYSTEM SET shared_buffers = '512MB';
>> ALTER SYSTEM
>> =# \q
>> $ pg_ctl -D d
On Sun, Dec 22, 2013 at 3:01 PM, Fujii Masao wrote:
> I found the bug of ALTER SYSTEM SET patch. The procedure to reproduce
> it is here.
>
> $ psql
> =# ALTER SYSTEM SET shared_buffers = '512MB';
> ALTER SYSTEM
> =# \q
> $ pg_ctl -D data reload
> server signaled
> 2013-12-22 18:24:13 JST LOG: re
On Fri, Dec 20, 2013 at 2:35 AM, Fujii Masao wrote:
> On Thu, Dec 19, 2013 at 2:21 PM, Tatsuo Ishii wrote:
>>> I found that the psql tab-completion for ALTER SYSTEM SET has not been
>>> implemented yet.
>>> Attached patch does that. Barring any objections, I will commit this patch.
>>
>> Good cat
On Thu, Dec 19, 2013 at 2:21 PM, Tatsuo Ishii wrote:
>> I found that the psql tab-completion for ALTER SYSTEM SET has not been
>> implemented yet.
>> Attached patch does that. Barring any objections, I will commit this patch.
>
> Good catch!
Committed.
Regards,
--
Fujii Masao
--
Sent via pg
> I found that the psql tab-completion for ALTER SYSTEM SET has not been
> implemented yet.
> Attached patch does that. Barring any objections, I will commit this patch.
Good catch!
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://ww
On Thu, Dec 19, 2013 at 12:08 PM, Amit Kapila wrote:
> On Wed, Dec 18, 2013 at 8:25 PM, Tatsuo Ishii wrote:
Is there any reason for the function returns int as it always returns
0 or 1. Maybe returns bool is better?
>>>
>>
>> I have committed your patches. Thanks.
>
> Thank you very muc
On Wed, Dec 18, 2013 at 8:25 PM, Tatsuo Ishii wrote:
>>> Is there any reason for the function returns int as it always returns
>>> 0 or 1. Maybe returns bool is better?
>>
>
> I have committed your patches. Thanks.
Thank you very much.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterpr
>> Is there any reason for the function returns int as it always returns
>> 0 or 1. Maybe returns bool is better?
>
> No, return type should be bool, I have changed the same in attached patch.
Confirmed.
>> 2) initdb.c
>>
>> + strcpy(tempautobuf, "# Do not edit this file manually! \n");
>>
On 12/18/2013 03:35 AM, Tatsuo Ishii wrote:
3) initdb.c
It seems the memory allocated for autoconflines[0] and
autoconflines[1] by pg_strdup is never freed.
(I think there's similar problem with "conflines" as well, though it
was not introduced by the patch).
Why would we care? initdb does
On Wed, Dec 18, 2013 at 2:05 PM, Tatsuo Ishii wrote:
> Hi,
>
> I have looked into this because it's marked as "ready for committer".
Thank you.
> It looks like working as advertised. Great! However I have noticed a
> few minor issues.
>
> 1) validate_conf_option
>
> +/*
> + * Validates configur
Hi,
I have looked into this because it's marked as "ready for committer".
> 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:
Greg Stark writes:
> Writing out each guc in a separate file is a singularly bad idea. It's
I'm not buying into any of your arguments here, and have something to
add to that part:
> I'm not even clear we do want this in /etc since none of our GUC
> options are repeatable things like Apache virtu
28 matches
Mail list logo
