On Mon, Dec 6, 2010 at 12:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> One possible way to do make an improvement in this area would be to >> move the responsibility for accepting connections out of the >> postmaster. Instead, you'd have a group of children that would all >> call accept() on the socket, and the OS would arbitrarily pick one to >> receive each new incoming connection. The postmaster would just be >> responsible for making sure that there were enough children hanging >> around. You could in fact make this change without doing anything >> else, in which case it wouldn't save any work but would possibly >> reduce connection latency a bit since more of the work could be done >> before the connection actually arrived. > > This seems like potentially a good idea independent of anything else, > just to reduce connection latency: fork() (not to mention exec() on > Windows) now happens before not after receipt of the connection request. > However, I see a couple of stumbling blocks: > > 1. Does accept() work that way everywhere (Windows, I'm looking at you)
Not sure. It might be useful to look at what Apache does, but I don't have time to do that ATM. > 2. What do you do when max_connections is exceeded, and you don't have > anybody at all listening on the socket? Right now we are at least able > to send back an error message explaining the problem. Sending back an error message explaining the problem seems like a non-negotiable requirement. I'm not quite sure how to dance around this. Perhaps if max_connections is exhausted, the postmaster itself joins the accept() queue and launches a dead-end backend for each new connection. Or perhaps we reserve one extra backend slot for a probably-dead-end backend that will just sit there and mail rejection notices; except that if it sees that a regular backend slot has opened up it grabs it and turns itself into a regular backend. > Another issue that would require some thought is what algorithm the > postmaster uses for deciding to spawn new children. But that doesn't > sound like a potential showstopper. The obvious algorithm would be to try to keep N spare workers around. Any time the number of unconnected backends drops below N the postmaster starts spawning new ones until it gets back up to N. I think the trick may not be the algorithm so much as finding a way to make the signaling sufficiently robust and lightweight. For example, I bet having each child that gets a new connection signal() the postmaster is a bad plan. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers