Re: ALTER SYSTEM SET command to change postgresql.conf parameters

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: amit(dot)kapila16(at)gmail(dot)com
Cc: haribabu(dot)kommi(at)huawei(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER SYSTEM SET command to change postgresql.conf parameters
Date: 2013-12-18 08:35:34
Message-ID: 20131218.173534.489368460725900966.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
> <haribabu(dot)kommi(at)huawei(dot)com> wrote:
>> On 19 November 2013 09:59 Amit Kapila wrote:
>>> On Mon, Nov 18, 2013 at 8:31 PM, Haribabu kommi
>>> <haribabu(dot)kommi(at)huawei(dot)com> wrote:
>>> > On 18 November 2013 20:01 Amit Kapila wrote:
>>> >> > Code changes are fine.
>>> >> > If two or three errors are present in the configuration file, it
>>> >> prints the last error
>>
>> Ok fine I marked the patch as ready for committer.
>
> Thanks for review.
>
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com

It looks like working as advertised. Great! However I have noticed a
few minor issues.

1) validate_conf_option

+/*
+ * Validates configuration parameter and value, by calling check hook functions
+ * depending on record's vartype. It validates if the parameter
+ * value given is in range of expected predefined value for that parameter.
+ *
+ * freemem - true indicates memory for newval and newextra will be
+ * freed in this function, false indicates it will be freed
+ * by caller.
+ * Return value:
+ * 1: the value is valid
+ * 0: the name or value is invalid
+ */
+int
+validate_conf_option(struct config_generic * record, const char *name,
+ const char *value, GucSource source, int elevel,
+ bool freemem, void *newval, void **newextra)

Is there any reason for the function returns int as it always returns
0 or 1. Maybe returns bool is better?

2) initdb.c

+ strcpy(tempautobuf, "# Do not edit this file manually! \n");
+ autoconflines[0] = pg_strdup(tempautobuf);
+ strcpy(tempautobuf, "# It will be overwritten by the ALTER SYSTEM command. \n");
+ autoconflines[1] = pg_strdup(tempautobuf);

Is there any reason to use "tempautobuf" here? I think we can simply change to this:

+ autoconflines[0] = pg_strdup("# Do not edit this file manually! \n");
+ autoconflines[1] = pg_strdup("# It will be overwritten by the ALTER SYSTEM command. \n");

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).

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yeb Havinga 2013-12-18 08:41:53 Re: [v9.4] row level security
Previous Message Christian Kruse 2013-12-18 08:30:20 Re: Patch: show xid and xmin in pg_stat_activity and pg_stat_replication