From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> |
Cc: | Alfred Perlstein <bright(at)wintelcom(dot)net>, pgsql-hackers(at)hub(dot)org |
Subject: | Re: Connection pooling. |
Date: | 2000-07-12 05:52:56 |
Message-ID: | 21892.963381176@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2000-07-12 06:13:38 | RE: Re: postgres TODO |
Previous Message | Philip Warner | 2000-07-12 05:40:38 | Re: Performance problem in aset.c |