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 1kkHT1-00062v-0P for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Dec 2020 02:02:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kkHSz-0003kd-Vd for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Dec 2020 02:02:01 +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 1kkHSz-0003kW-On for pgsql-hackers@lists.postgresql.org; Wed, 02 Dec 2020 02:02:01 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kkHSw-000548-SF for pgsql-hackers@postgresql.org; Wed, 02 Dec 2020 02:02:01 +0000 Received: from hnk.local (p1295030-ipngn4902funabasi.chiba.ocn.ne.jp [153.166.85.30]) by oss.nttdata.com (Postfix) with ESMTPSA id E2A4D6243F; Wed, 2 Dec 2020 11:01:52 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.3 at oss.nttdata.com Subject: Re: Allow some recovery parameters to be changed with reload To: Kyotaro Horiguchi Cc: sk@zsrv.org, a.lubennikova@postgrespro.ru, robertmhaas@gmail.com, michael@paquier.xyz, andres@anarazel.de, peter.eisentraut@2ndquadrant.com, pgsql-hackers@postgresql.org References: <20201127.093040.1121089236433501638.horikyota.ntt@gmail.com> <44876a44-60a9-c45e-15a2-5fe3239f0a09@oss.nttdata.com> <20201127.120545.1039699675559027058.horikyota.ntt@gmail.com> From: Fujii Masao Message-ID: Date: Wed, 2 Dec 2020 11:01:52 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201127.120545.1039699675559027058.horikyota.ntt@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020/11/27 12:05, Kyotaro Horiguchi wrote: > At Fri, 27 Nov 2020 09:48:25 +0900, Fujii Masao wrote in >> >> >> On 2020/11/27 9:30, Kyotaro Horiguchi wrote: >>> At Thu, 26 Nov 2020 22:43:48 +0900, Fujii Masao >>> wrote in >>>> >>>> >>>> On 2020/11/12 4:38, Sergei Kornilov wrote: >>>>> Hello >>>>> >>>>>> Anyway, for now I think that your first patch would be enough, i.e., >>>>>> just change the context of restore_command to PGC_SIGHUP. >>>>> Glad to hear. Attached a rebased version of the original proposal. >>>> >>>> Thanks for rebasing the patch! >>>> >>>> This parameter is required for archive recovery, >>>> >>>> I found the above description in config.sgml. I was just wondering >>>> if it should be updated so that the actual specification is described >>>> or not. >>>> The actual spec is that restore_command is required to start archive >>>> recovery, but optional (i.e., the parameter can be reset to an empty) >>>> after archive recovery has started. But this updated version of >>>> description would be rather confusing to users. So I'm now thinking >>>> not to update that. >>>> >>>> Does anyone object to the patch? If no, I'm thinking to commit the >>>> patch. >>> Although I don't object to make the parameter reloadable, I think it >>> needs to be documented that server could stop after reloading if the >>> server failed to execute the new command line. >> >> You mean that we should document that if restore_command is set to >> improper command mistakenly, archive recovery may fail to restore some >> archived WAL files and finish without replaying those WAL? But isn't >> this true even without applying the patch? > > If we set a wrong command in .conf and start the server in recovery > mode, the server immediately stops. It's fine. If we change > restore_command wrong way on a running server, "pg_ctl reload" stops > the server. If it is a hot standby, the server stops unexpectedly. > > However, after rechecking, I found that recovery_end_command with > wrong content causes server stop at the end of recovery, or at > promotion. And that variable is PGC_SIGHUP. > > So I agree not to document that. Sorry for the noise. OK, so I pushed the patch. Thanks! Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION