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: Andres Freund <andres@anarazel.de>, 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-21T18:43:30Z
Lists: pgsql-hackers 
Stephen Frost <sfrost@snowman.net> writes:
> * Andres Freund (andres@anarazel.de) wrote:
>> On 2021-04-20 14:56:58 -0400, Tom Lane wrote:
>>> 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"?

>> Unfortunately I think something like a percentage is hard to calculate
>> right now.

> While it obviously wouldn't be exactly accurate, I wonder if we couldn't
> just look at the WAL files we have to reply and then guess that we'll go
> through about half of them before we reach the end..?  I mean, wouldn't
> exactly be the first time that a percentage progress report wasn't
> completely accurate. :)

Or we could skip all the guessing and just print something like what
the startup process exposes in ps status, ie "currently processing
WAL file so-and-so".

			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.