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 1kb9PZ-0001Di-Cu for pgsql-hackers@arkaria.postgresql.org; Fri, 06 Nov 2020 21:36:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kb9PX-0007As-Ca for pgsql-hackers@arkaria.postgresql.org; Fri, 06 Nov 2020 21:36:43 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kb9PX-0007Al-0f for pgsql-hackers@lists.postgresql.org; Fri, 06 Nov 2020 21:36:43 +0000 Received: from forward500o.mail.yandex.net ([37.140.190.195]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kb9PS-0000dk-Bv for pgsql-hackers@postgresql.org; Fri, 06 Nov 2020 21:36:41 +0000 Received: from mxback19j.mail.yandex.net (mxback19j.mail.yandex.net [IPv6:2a02:6b8:0:1619::95]) by forward500o.mail.yandex.net (Yandex) with ESMTP id E54DF6007F; Sat, 7 Nov 2020 00:36:34 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback19j.mail.yandex.net (mxback/Yandex) with ESMTP id jWzndpVe4k-aXMu6NNG; Sat, 07 Nov 2020 00:36:34 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zsrv.org; s=mail; t=1604698594; bh=0ooyedc4oVv3MzftxVkGnl/DPmLuEZgUqMpZGTXr6ZU=; h=Message-Id:Cc:Subject:In-Reply-To:Date:References:To:From; b=jM6QWBP8d4TTgDZRrKtI6CsTfZsB6ZEp3PTdXl7K3mLnhnzmdOXDNW0G5aqKDPLke u2esNe5qhTOFw9W4rWBLRNBgd19d/LQ8K80fJlaUguJ+Sut/X2cg21snkQjvPno+Sp LDjdK0eT9i09bsc+QFIRYt5kbC+pfhhLi5JuCAU8= Authentication-Results: mxback19j.mail.yandex.net; dkim=pass header.i=@zsrv.org Received: by sas1-e05fd3bc78f9.qloud-c.yandex.net with HTTP; Sat, 07 Nov 2020 00:36:33 +0300 From: Sergei Kornilov To: Fujii Masao , Kyotaro Horiguchi , "a.lubennikova@postgrespro.ru" Cc: "robertmhaas@gmail.com" , "michael@paquier.xyz" , "andres@anarazel.de" , "peter.eisentraut@2ndquadrant.com" , "pgsql-hackers@postgresql.org" In-Reply-To: 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> Subject: Re: Allow some recovery parameters to be changed with reload MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sat, 07 Nov 2020 00:36:33 +0300 Message-Id: <108021604695421@mail.yandex.ru> Content-Transfer-Encoding: 7bit Content-Type: text/plain List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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. Did not notice anything around StandbyMode conditions. regards, Sergei