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 1kcur0-0001H4-1x for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Nov 2020 18:28:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kcuqy-00020E-V4 for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Nov 2020 18:28:20 +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 1kcuqy-000206-O7 for pgsql-hackers@lists.postgresql.org; Wed, 11 Nov 2020 18:28:20 +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 1kcuqr-0006BT-Oh for pgsql-hackers@postgresql.org; Wed, 11 Nov 2020 18:28:20 +0000 Received: from hnk.local (p1295030-ipngn4902funabasi.chiba.ocn.ne.jp [153.166.85.30]) by oss.nttdata.com (Postfix) with ESMTPSA id 0866662426; Thu, 12 Nov 2020 03:28:07 +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: Sergei Kornilov , Kyotaro Horiguchi , "a.lubennikova@postgrespro.ru" Cc: "robertmhaas@gmail.com" , "michael@paquier.xyz" , "andres@anarazel.de" , "peter.eisentraut@2ndquadrant.com" , "pgsql-hackers@postgresql.org" References: <20200809052149.GB17986@paquier.xyz> <1741c40b-73e3-133b-77e6-05ebc7bf3c0f@postgrespro.ru> <20201022.110026.524650499365127827.horikyota.ntt@gmail.com> <4920201603879284@mail.yandex.ru> <0e0d5982-ac64-818d-1ec6-18a80b9300b1@oss.nttdata.com> <56311604665173@mail.yandex.ru> <108021604695421@mail.yandex.ru> From: Fujii Masao Message-ID: Date: Thu, 12 Nov 2020 03:28:06 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.4.2 MIME-Version: 1.0 In-Reply-To: <108021604695421@mail.yandex.ru> 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/07 6:36, Sergei Kornilov wrote: > Hello > >> I'm wondering if it's safe to allow restore_command to be emptied during >> archive recovery. Even when it's emptied, archive recovery can proceed >> by reading WAL files from pg_wal directory. This is the same behavior as >> when restore_command is set to, e.g., /bin/false. > > I am always confused by this implementation detail. restore_command fails? Fine, let's just read file from pg_wal. But this is different topic... > > I do not know the history of this fatal ereport. It looks like "must specify restore_command when standby mode is not enabled" check is only intended to protect the user from misconfiguration and the rest code will treat empty restore_command correctly, just like /bin/false. Maybe. Anyway, for now I think that your first patch would be enough, i.e., just change the context of restore_command to PGC_SIGHUP. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION