Horton

Re: when the startup process doesn't

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Magnus Hagander <magnus@hagander.net>, Jehan-Guillaume de Rorthais <jgdr@dalibo.com>, Robert Haas <robertmhaas@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-04-20T18:56:58Z
Lists: pgsql-hackers 
Stephen Frost <sfrost@snowman.net> 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

Commits

  1. Un-revert "Disable STARTUP_PROGRESS_TIMEOUT in standby mode."

  2. Revert "Disable STARTUP_PROGRESS_TIMEOUT in standby mode."

  3. Disable STARTUP_PROGRESS_TIMEOUT in standby mode.

  4. Fix race condition in startup progress reporting.

  5. Report progress of startup operations that take a long time.

  6. Add enable_timeout_every() to fire the same timeout repeatedly.