On Tue, Aug 14, 2012 at 06:53:49PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +