Re: Connection pooling.

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
> Seems a lot trickier than you think. A backend can only be running
> one transaction at a time, so you'd have to keep track of which backends
> are in the middle of a transaction. I can imagine race conditions here.

Aborting out of a transaction is no problem; we have code for that
anyway.  More serious problems:

* We have no code for reassigning a backend to a different database, so the pooling would have to be per-database.

* AFAIK there is no portable way to pass a socket connection from the postmaster to an already-existing backend
process. If you do a fork() then the connection is inherited ... otherwise you've got a problem.  (You could work
aroundthis if the postmaster relays every single byte in both directions between client and backend, but the
performanceproblems with that should be obvious.)
 

> And backends can have contexts that are set by various clients using
> SET and friends.

Resetting SET variables would be a problem, and there's also the
assigned user name to be reset.  This doesn't seem impossible, but
it does seem tedious and error-prone.  (OTOH, Peter E's recent work
on guc.c might have unified option-handling enough to bring it
within reason.)

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.
        regards, tom lane