Thread: Re: POC: Carefully exposing information without authentication

Greg Sabino Mullane <htamfids@gmail.com> wrote:

> Proposal: Allow a carefully curated selection of information to be shown without authentication.
>
> A common task for an HA system or a load balancer is to quickly determine which of your Postgres clusters is the
primary,and which are the 
> replicas. The canonical way to do this is to log in to each server with a valid username and password, and then run
pg_is_in_recovery().
> That's a lot of work to determine if a server is a replica or not, and it struck me that this true/false information
abouta running cluster is not 
> super-sensitive information. In other words, would it really be wrong if there was a way to advertise that
informationwithout having to log in? 
> I toyed with the idea of Postgres maintaining some sort of signal file, but then I realized that we already have a
process,listening on a known 
> port, that has that information available to us.
>
> Thus, this POC (proof of concept), which lets the postmaster scan for incoming requests and quickly handle them
*before*doing forking and 
> authenticating. We scan for a simple trigger string, and immediately return the information to the client.

Why is it important not to fork?  My understanding is that pg_is_ready also
tries to start a regular connection, i.e. forks a new backend. I think this
functionality would fit into libpq. (I've got no strong opinion on the amount
of information to be revealed this way. In any case, a GUC to enable the
feature only if the DBA wants it makes sense.)

--
Antonin Houska
Web: https://www.cybertec-postgresql.com

Greg Sabino Mullane <htamfids@gmail.com> writes:
> Good question. Forking is expensive, and there is also a lot of
> housekeeping associated with it that is simply not needed here. We want
> this to be lightweight, and simple. No need to fork if we are just going to
> do a few strncmp() calls and a send().

send() can block.  I think calling it in the postmaster is a
nonstarter.  For comparison, we make an effort to not do any
communication with incoming clients until after forking a child
to do the communication.  The one exception is if we have to
report fork failure --- but we don't make any strong guarantees
about that report succeeding.  (IIRC, we put the port into nonblock
mode and try only once.)  That's probably not a behavior you want
to adopt for non-edge-case usages.

Another point is that you'll recall that there's a lot of
interest in switching to a threaded model.  The argument that
"fork is too expensive" may not have a long shelf life.

I'm not taking a position on whether $SUBJECT is a good idea
in the first place.

            regards, tom lane