On Mon, Apr 19, 2021 at 8:44 PM Tom Lane <t...@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. 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. -- Robert Haas EDB: http://www.enterprisedb.com
