Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pkpwu-00067i-LM for pgsql-hackers@arkaria.postgresql.org; Fri, 07 Apr 2023 17:32:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pkpwt-0008ED-H3 for pgsql-hackers@arkaria.postgresql.org; Fri, 07 Apr 2023 17:32:31 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pkpwt-0008E3-7d for pgsql-hackers@lists.postgresql.org; Fri, 07 Apr 2023 17:32:31 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pkpwp-001TvW-8n for pgsql-hackers@lists.postgresql.org; Fri, 07 Apr 2023 17:32:30 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 337HWMDT3049105; Fri, 7 Apr 2023 13:32:22 -0400 From: Tom Lane To: "wangw.fnst@fujitsu.com" cc: Nathan Bossart , "pgsql-hackers@lists.postgresql.org" Subject: Re: Fix the description of GUC "max_locks_per_transaction" and "max_pred_locks_per_transaction" in guc_table.c In-reply-to: References: <20230222003716.GA8100@nathanxps13> <20230222170737.GA10734@nathanxps13> <1515917.1680623251@sss.pgh.pa.us> Comments: In-reply-to "wangw.fnst@fujitsu.com" message dated "Fri, 07 Apr 2023 08:46:37 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3049103.1680888742.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 07 Apr 2023 13:32:22 -0400 Message-ID: <3049104.1680888742@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "wangw.fnst@fujitsu.com" writes: > On Tues, Apr 4, 2023 at 23:48 PM Tom Lane wrote: >> I like the "per eligible process" wording, at least for guc_tables.c; >> or maybe it could be "per server process"? That would be more >> accurate and not much longer than what we have now. > Thanks both for sharing your opinions. > I agree that verbose descriptions make maintenance difficult. > For consistency, I unified the formulas in guc_tables.c and pg-doc into = the same > suggested short formula. Attach the new patch. After studying this for awhile, I decided "server process" is probably the better term --- people will have some idea what that means, while "eligible process" is not a term we use anywhere else. Pushed with that change and some minor other wordsmithing. regards, tom lane