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

On 03.09.2012 03:23, Tom Lane wrote:
> 1. As you can see above, the feature is triggered by specifying the new
> connection option "standalone_datadir", whose value must be the location
> of the data directory.  I also invented an option "standalone_backend",
> which can be set to specify which postgres executable to launch.  If the
> latter isn't specified, libpq defaults to trying the installation PGBINDIR
> that was selected by configure.  (I don't think it can use the relative
> path tricks we use in pg_ctl and elsewhere, since there's no good reason
> to assume that it's running in a Postgres-supplied program.)  I'm not
> particularly wedded to these names or the syntax, but I think this is the
> basic functionality we'd need.

Are there security issues with this? If a user can specify libpq 
connection options, he can now execute any file he wants by passing it 
as standalone_backend. Granted, you shouldn't allow an untrusted user to 
specify libpq connection options, because allowing to open a TCP 
connection to an arbitrary address can be a problem by itself, but it 
seems like this might make the situation much worse. contrib/dblink 
springs to mind..

> 3. The bulk of the changes have to do with the fact that we need to keep
> track of two file descriptors not one.  This was a bit tedious, but fairly
> straightforward --- though I was surprised to find that send() and recv()
> don't work on pipes, at least not on Linux.  You have to use read() and
> write() instead.

Would socketpair(2) be simpler?

> 7. I haven't tried to make pg_upgrade use this yet.

Hmm, pg_upgrade uses pg_dumpall rather than pg_dump, so it needs to 
connect once per database. That means launching the standalone backend 
multiple times. I guess that works, as long as pg_dumpall doesn't try to 
hold multiple connections open at any one time.

- Heikki