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