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
