At 01:52 12/07/00 -0400, Tom Lane wrote:
>
>The killer problem here is that you can't hand off a connection
>accepted by the postmaster to a backend except by fork() --- at least
>not with methods that work on a wide variety of Unixen. Unless someone
>has a way around that, I think the idea is dead in the water; the lesser
>issues don't matter.
>
My understanding of pg client interfaces is that the client uses ont of the
pg interface libraries to make a connection to the db; they specify host &
port and get back some kind of connection object.
What stops the interface library from using the host & port to talk to the
postmaster, find the host & port the spare db server, then connect directly
to the server? This second connection is passed back in the connection object.
When the client disconnects from the server, it tells the postmaster it's
available again etc.
ie. in very rough terms:
client calls interface to connect
interface talks to postmaster on port 5432, says "I want a server for
xyz db"
postmaster replies with "Try port ABCD" OR "no servers available" postmaster marks the nominated server as 'used'
postmaster disconnects from client
interface connects to port ABCD as per normal protocols interface fills in connection object & returns
...client does some work...
client disconnects
db server tells postmaster it's available again.
There would also need to be timeout code to handle the case where the
interface did not do the second connect.
You could also have the interface allocate a port send it's number to the
postmaster then listen on it, but I think that would represent a potential
security hole.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \| | --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
