Re: Proof of concept: standalone backend with full FE/BE protocol - Mailing list pgsql-hackers

So, in the spirit of not painting ourselves into a tiny corner here on
the whole "single backend" and "embedded database" problem with pg
options, can we generalize this a bit?

Any way we could make psql connect to a "given fd", as an option?  In
theory, that could be something opened by some out-side-of-postgresql
tunnel with 3rd party auth in the same app that uses libpq directly,
or it could be a fd prepared  by something that specifically launched
a single-backend postgres, like in the case of pg_upgrade, pg_uprade
itself, and passed to psql, etc, which would be passed in as options.

In theory, that might even allow the possibility of starting the
single-backend only once and passing it to multiple clients in
succession, instead of having to stop/start the backend between each
client.  And it would allow the possiblity of "something" (pg_upgrade,
or some other application) to control the start/stop of the backend
outside the libpq connection.

Now, I'm familiar with the abilities related to passing fd's around in
Linux, but have no idea if we'd have comparable methods to use on
Windows.

a.

On Wed, Sep 5, 2012 at 8:11 PM, Daniel Farina <daniel@heroku.com> wrote:
> On Wed, Sep 5, 2012 at 3:17 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> On 9/5/12 5:59 PM, Daniel Farina wrote:
>>> I agree with this, even though in theory (but not in practice)
>>> creative use of unix sockets (sorry windows, perhaps some
>>> port-allocating and URL mangling can be done instead) and conventions
>>> for those would allow even better almost-like-embedded results,
>>> methinks.  That may still be able to happen.
>>
>> Sure, everyone who cares can already do this, but some people probably
>> don't care enough.  Also, making this portable and robust for everyone
>> to use, not just your local environment, is pretty tricky.  See
>> pg_upgrade test script, for a prominent example.
>
> To my knowledge, no one has even really seriously tried to package it
> yet and then told the tale of woe, and it was an especially
> un-gratifying exercise for quite a while on account of multiple
> postgreses not getting along on the same machine because of SysV
> shmem.
>
> The bar for testing is a lot different than pg_upgrade (where a
> negative consequence is confusing and stressful downtime), and many
> programs use fork/threads and multiple connections even in testing,
> making its requirements different.
>
> So consider me still skeptical given the current reasoning that unix
> sockets can't be a good-or-better substitute, and especially
> accounting for programs that need multiple backends.
>
> --
> fdr
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>



-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.