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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
