Re: pg_upgrade improvements

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Harold Giménez <harold(dot)gimenez(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_upgrade improvements
Date: 2012-04-05 13:46:54
Message-ID: 1469.1333633614@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Apr 4, 2012 at 11:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Yeah. IMO the right long-term fix is to be able to run pg_dump and psql
>> talking to a standalone backend, but nobody's gotten round to making
>> that possible.

> Are you thinking about something like postgres --single
> --port=PORT_NUMBER_OR_SOCKET_DIRECTORY?

No, opening up a port is exactly what we *don't* want it to do.
Otherwise you're right back to worrying about how to make sure that
unwanted connections don't get in. Notions like private socket
directories don't solve this because we don't have that option
available on Windows.

The vague idea I had was for libpq to have a connection option that
would cause it to spawn a standalone backend as a child process and
communicate with that over two pipes, just like any popen'd process.
The backend would see this exactly like standalone mode now, except for
speaking FE/BE protocol over its stdin/stdout rather than the existing
ad-hoc user interface for standalone mode.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-04-05 14:01:57 Re: bugfix for cursor arguments in named notation
Previous Message Robert Haas 2012-04-05 13:34:56 Re: pg_upgrade improvements