Re: Connection pooling.

Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)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 around this if the postmaster relays
every single byte in both directions between client and backend,
but the performance problems 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