Re: Proof of concept: standalone backend with full FE/BE protocol

On Thu, Dec 5, 2013 at 3:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'm pretty much persuaded by Andres' point that we should not allow a
> child process to be launched under a client app without clear permission
> from the code of the app (and *not* just some environment variable that
> might have been set far away, perhaps by someone who doesn't know what the
> app assumes about SIGCHLD etc). So a separate connection call seems like
> not a bad idea. In the case of psql and pg_dump it'd be reasonable to
> invent a separate command line switch that drives use of this call instead
> of normal PQconnect. Doing that, and *not* allowing the text of the
> connection string to determine it, seems like it pretty well solves any
> security objections.

Yep.

> It might be unpleasant to use in some cases, though.

Why would there be more than a few cases in the first place? Who is
going to use this beyond psql, pg_dump(all), and pg_upgrade, and why?

> Another issue is that we have too many variants of PQconnect already;
> which of them are we prepared to clone for this hypothetical new
> connection method?

PQconnectdbParams, I assume. Isn't that the one to rule them all,
modulo async connect which I can't think is relevant here?

Or don't clone that one but instead have
PQnextConnectionShouldForkThisBinary('...') and let the psql/pg_dump
switch be --standalone=full-path-to-the-postgres-binary.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company