On Tue, Aug 14, 2012 at 06:53:49PM -0400, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > On Tue, Aug 14, 2012 at 05:56:39PM -0400, Tom Lane wrote: > >> The implementation I'm visualizing is that a would-be client (think psql > >> or pg_dump, though the code would actually be in libpq) forks off a > >> process that becomes a standalone backend, and then they communicate > >> over a pair of pipes that were created before forking. This is > >> implementable on any platform that supports Postgres, because initdb > >> already relies on equivalent capabilities. > > > I think the big question is whether we need to modify every binary that > > pg_upgrade executes to understand this pipe communication method. > > I think we can fix it once in libpq and we're done. It'd be driven > by some new connection-string option, and the clients as such would > never need to know that they're not talking to a regular postmaster.
OK, I like the idea if we can make it work. I am unclear how we would pass this connection thing. Peter's idea of putting the socket in the current directory is great, except for Windows support. Maybe we should just implement this for non-Windows. FYI, we only use new binaries, so we would only need the support in the new libpq client libraries. However, we can't backpatch this into the old servers, so I am concerned it will not be possible to implement this if it requires server changes. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
