Re: when the startup process doesn't - Mailing list pgsql-hackers

From Andres Freund
Subject Re: when the startup process doesn't
Date
Msg-id 20210420203642.nvxvolm37f2k6prj@alap3.anarazel.de
Whole thread Raw
In response to Re: when the startup process doesn't  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: when the startup process doesn't  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Hi,

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.  Even just looking at crash recovery (vs replication or
PITR), we don't currently know where the WAL ends without reading all
the WAL. The easiest thing to return would be something in LSNs or
bytes and I suspect that we don't want to expose either unauthenticated?

I wonder if we ought to occasionally update something like
ControlFileData->minRecoveryPoint on primaries, similar to what we do on
standbys? Then we could actually calculate a percentage, and it'd have
the added advantage of allowing to detect more cases where the end of
the WAL was lost. Obviously we'd have to throttle it somehow, to avoid
adding a lot of fsyncs, but that seems doable?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: when the startup process doesn't
Next
From: Alvaro Herrera
Date:
Subject: Re: when the startup process doesn't