Re: when the startup process doesn't

On Tue, Apr 20, 2021 at 2:43 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Mon, Apr 19, 2021 at 8:44 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Hmm ... +1 for progress messages in the log, but I'm suspicious about
> > the complexity-and-fragility-versus-value tradeoff for the other thing.
>
> All right, so it's nice to hear that nobody so far is opposed to the
> log-based solution, and I think it's sensible to think about building
> that one first and doing anything else later.
>
> But, if we did want to invent something to allow monitoring via libpq
> even at this early stage, how would we make it work? Magnus pointed
> out that we can hardly read pg_authid during crash recovery, which
> means that accepting logins in the usual sense at that stage is not
> feasible. But, what if we picked a fixed, hard-coded role name for
> this? I would suggest pg_monitor, but that's already taken for
> something else, so maybe pg_console or some better thing someone else
> can suggest. Without a pg_authid row, you couldn't use password, md5,
> or scram authentication, unless we provided some other place to store
> the verifier, like a flatfile. I'm not sure we want to go there, but
> that still leaves a lot of workable authentication methods.

Another option would be to keep this check entirely outside the scope
of normal roles, and just listen on a port (or unix socket) during
startup which basically just replies with the current status if you
connect to it. On Unix this could also make use of peer authentication
requiring you to be the same user as postgres for example.


> I think Álvaro is right to see this kind of work as an extension of
> pg_isready, but the problem with pg_isready is that we don't want to
> expose a lot of information to the whole Internet, or however much of
> it can reach the postgres port. But with this approach, you can lock
> down access via pg_hba.conf, which means that it's OK to expose
> information that we don't want to make available to everyone. I think
> we're still limited to exposing what can be observed from shared
> memory here, because the whole idea is to have something that can be
> used even before consistency is reached, so we shouldn't really be
> doing anything that would look at the contents of data files. But that
> still leaves a bunch of things that we could show here, the progress
> of the startup process being one of them.

Yeah, I think we should definitely limit this to local access, one way
or another. Realistically using pg_hba is going to require catalog
access, isn't it? And we can't just go ignore those rows in pg_hba
that for example references role membership (as well as all those auth
methods you can't use).

--
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/