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 1lYvYd-0006Ss-Jf for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Apr 2021 18:57:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lYvYc-0006jP-Hu for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Apr 2021 18:57:10 +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 1lYvYc-0006jA-BE for pgsql-hackers@lists.postgresql.org; Tue, 20 Apr 2021 18:57:10 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lYvYa-0003vy-CP for pgsql-hackers@postgresql.org; Tue, 20 Apr 2021 18:57:10 +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 13KIuwKM633338; Tue, 20 Apr 2021 14:56:58 -0400 From: Tom Lane To: Stephen Frost cc: Magnus Hagander , Jehan-Guillaume de Rorthais , Robert Haas , Thomas Munro , "pgsql-hackers@postgresql.org" Subject: Re: when the startup process doesn't In-reply-to: <20210420185150.GL20766@tamriel.snowman.net> References: <465221.1618879471@sss.pgh.pa.us> <20210420171720.56599607@firost> <631849.1618942988@sss.pgh.pa.us> <20210420185150.GL20766@tamriel.snowman.net> Comments: In-reply-to Stephen Frost message dated "Tue, 20 Apr 2021 14:51:50 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <633336.1618945018.1@sss.pgh.pa.us> Date: Tue, 20 Apr 2021 14:56:58 -0400 Message-ID: <633337.1618945018@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Stephen Frost writes: > Yeah, being able to pick up on this remotely seems like it'd be quite > nice. I'm not really thrilled with the idea, but the best I've got > offhand for this would be a new role that's "pg_recovery_login" where an > admin can GRANT that role to the roles they'd like to be able to use to > login during the recovery process and then, for those roles, we write > out flat files to allow authentication without access to pg_authid, We got rid of those flat files for good and sufficient reasons. I really really don't want to go back to having such. I wonder though whether we really need authentication here. pg_ping already exposes whether the database is up, to anyone who can reach the postmaster port at all. Would it be so horrible if the "can't accept connections" error message included a detail about "recovery is X% done"? regards, tom lane