Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qlllt-004HEj-VA for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Sep 2023 07:49:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qlllr-00A97l-Ut for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Sep 2023 07:49:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qlllr-00A977-K8 for pgsql-hackers@lists.postgresql.org; Thu, 28 Sep 2023 07:49:16 +0000 Received: from mail-pl1-x62f.google.com ([2607:f8b0:4864:20::62f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qlllm-0082xn-8N for pgsql-hackers@lists.postgresql.org; Thu, 28 Sep 2023 07:49:12 +0000 Received: by mail-pl1-x62f.google.com with SMTP id d9443c01a7336-1c6219307b2so58257915ad.1 for ; Thu, 28 Sep 2023 00:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695887347; x=1696492147; darn=lists.postgresql.org; h=content-transfer-encoding:mime-version:user-agent:from:subject:to :message-id:date:from:to:cc:subject:date:message-id:reply-to; bh=B9C1ldhsYup9qQL+HnfRsMAPAqP8y/dT37hJxHYYdKM=; b=mKlrVReV/AApgrPh+EsGuF0PO7MHsW2C8QZEZe0slYS36MPSIDkihbaw9q8J5oHDsr /xx36Y7QoLZsYVqK0TNK9j61JF9ssB7UZrGcPLSZKoS91XZq7dC6B6bAgeY7j70M6N7H fEULomqtElkpabmKkwGlQiE0GofngkftmJWnrDXZ5AM1L2wY3AxSuBqm2oKgmAzAbpta Y6xqD4jlTnD5Cet7hEs6GITwX5WtfCWNDoOJ89QPjBsQvdILYVoh28oFiI8k+JQfyMro oyvtBGh5zvV/gDckX2e9LUgfG5po4VcfqQ0Vf5238t6ShWtHxML6YPBM+zGqlpeaT6dE Q9XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695887347; x=1696492147; h=content-transfer-encoding:mime-version:user-agent:from:subject:to :message-id:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=B9C1ldhsYup9qQL+HnfRsMAPAqP8y/dT37hJxHYYdKM=; b=OYvKp0g5c9DPNIoW0pLeF3wy3KVeOTrFeF0oBilZtQOajSmiiTU6sO5ZPdE+Q/aApd W79ZEo99PEsobOz9SUW5eTtrVXni1F1MIvmTnD7tvBNBajQiRF0iYw+EOJXStc8VNZ2h xusIOFEXJArGzOR2JEOIVoi+yaueZYVEGX/BOCySATrqcyHA7kdnEfewNQltB4/Uuh6V MZ1aQAjvvAqKLKrIEK6ivSPZbTkd1J5oOrHaU0ZBOOh3DHuWPIR6lblw8omHCqJklhtl jHDJSYf2gSOCg7N/Oz+g7zJYwQ5yBUwVRpy5khOvaDzLRp0lMCBW1ywNwuebn9wUFZsH do7A== X-Gm-Message-State: AOJu0YzcWe/6619x56WkPJJqjkbnwOys3CkvWn9oodY5inkC3ZZYJ34V cENcPxfBIp7oizbfcCiCTb9A03SdfRw= X-Google-Smtp-Source: AGHT+IE3dWyReECnwmMUBDG62UHJlWtH9JFSNOWRDLNE726PYBFP+dFNGLsWtj/jKUot/SwfyFz9+w== X-Received: by 2002:a17:902:c14c:b0:1c6:2b5e:824e with SMTP id 12-20020a170902c14c00b001c62b5e824emr428349plj.28.1695887346843; Thu, 28 Sep 2023 00:49:06 -0700 (PDT) Received: from localhost (KD036014041111.ppp-bb.dion.ne.jp. [36.14.41.111]) by smtp.gmail.com with ESMTPSA id n3-20020a170902d2c300b001c737950e4dsm646070plc.2.2023.09.28.00.49.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Sep 2023 00:49:06 -0700 (PDT) Date: Thu, 28 Sep 2023 16:49:04 +0900 (JST) Message-Id: <20230928.164904.2153358973162534034.horikyota.ntt@gmail.com> To: pgsql-hackers@lists.postgresql.org Subject: initdb's -c option behaves wrong way? From: Kyotaro Horiguchi User-Agent: Mew version 6.8 on Emacs 27.2 Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Sep_28_16_49_04_2023_929)--" Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ----Next_Part(Thu_Sep_28_16_49_04_2023_929)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello. I noticed that -c option of initdb behaves in an unexpected manner. Identical variable names with variations in letter casing are treated as distinct variables. $ initdb -cwork_mem=100 -cWORK_MEM=1000 -cWork_mem=2000 ... $ grep -i 'work_mem ' $PGDATA/postgresql.conf work_mem = 100 # min 64kB #maintenance_work_mem = 64MB # min 1MB #autovacuum_work_mem = -1 # min 1MB, or -1 to use maintenance_work_mem #logical_decoding_work_mem = 64MB # min 64kB WORK_MEM = 1000 Work_mem = 2000 The original intention was apparently to overwrite the existing line. Furthermore, I surmise that preserving the original letter casing is preferable. Attached is a patch to address this issue. To retrieve the variable name from the existing line, the code is slightly restructured. Alternatively, should we just down-case the provided variable names? regards. -- Kyotaro Horiguchi NTT Open Source Software Center ----Next_Part(Thu_Sep_28_16_49_04_2023_929)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="initdb-c_ignore_letter_case.patch" diff --git a/src/bin/initdb/initdb.c b/src/bin/initdb/initdb.c index 0c6f5ceb0a..04419840f4 100644 --- a/src/bin/initdb/initdb.c +++ b/src/bin/initdb/initdb.c @@ -470,20 +470,14 @@ replace_guc_value(char **lines, const char *guc_name, const char *guc_value, int namelen = strlen(guc_name); PQExpBuffer newline = createPQExpBuffer(); int i; + const char *where; + const char *pname; - /* prepare the replacement line, except for possible comment and newline */ if (mark_as_comment) appendPQExpBufferChar(newline, '#'); - appendPQExpBuffer(newline, "%s = ", guc_name); - if (guc_value_requires_quotes(guc_value)) - appendPQExpBuffer(newline, "'%s'", escape_quotes(guc_value)); - else - appendPQExpBufferStr(newline, guc_value); for (i = 0; lines[i]; i++) { - const char *where; - /* * Look for a line assigning to guc_name. Typically it will be * preceded by '#', but that might not be the case if a -c switch @@ -493,15 +487,32 @@ replace_guc_value(char **lines, const char *guc_name, const char *guc_value, where = lines[i]; while (*where == '#' || isspace((unsigned char) *where)) where++; - if (strncmp(where, guc_name, namelen) != 0) + if (strncasecmp(where, guc_name, namelen) != 0) continue; + + pname = where; where += namelen; while (isspace((unsigned char) *where)) where++; - if (*where != '=') - continue; - /* found it -- append the original comment if any */ + /* assume there's only one match */ + if (*where == '=') + break; + } + + if (lines[i]) + { + /* found it, rewrite the line preserving the original comment if any */ + appendPQExpBuffer(newline, "%.*s = ", namelen, pname); + if (guc_value_requires_quotes(guc_value)) + appendPQExpBuffer(newline, "'%s'", escape_quotes(guc_value)); + else + appendPQExpBufferStr(newline, guc_value); + + /* + * completed body of line, now continue with potential indentation and + * comment + */ where = strrchr(where, '#'); if (where) { @@ -548,16 +559,19 @@ replace_guc_value(char **lines, const char *guc_name, const char *guc_value, free(lines[i]); lines[i] = newline->data; - - break; /* assume there's only one match */ } - - if (lines[i] == NULL) + else { /* * No match, so append a new entry. (We rely on the bootstrap server * to complain if it's not a valid GUC name.) */ + appendPQExpBuffer(newline, "%s = ", guc_name); + if (guc_value_requires_quotes(guc_value)) + appendPQExpBuffer(newline, "'%s'", escape_quotes(guc_value)); + else + appendPQExpBufferStr(newline, guc_value); + appendPQExpBufferChar(newline, '\n'); lines = pg_realloc_array(lines, char *, i + 2); lines[i++] = newline->data; ----Next_Part(Thu_Sep_28_16_49_04_2023_929)----