Jim C. Nasby wrote: > On Mon, Jan 22, 2007 at 04:24:28PM -0300, Alvaro Herrera wrote: > > 4. Launcher will be a continuously-running process, akin to bgwriter; > > connected to shared memory > > So would it use up a database connection?
No. It's connected to shared memory and has access to pgstats, but it's not connected to any database so it's not counted. You'd say it has the same status as the bgwriter. > > 5. Workers will be direct postmaster children; so postmaster will get > > SIGCHLD when worker dies > > As part of this I think we need to make it more obvious how all of this > ties into max_connections. Currently, autovac ties up one of the > super-user connections whenever it's not asleep; these changes would > presumably mean that more of those connections could be tied up. Sure. > Rather than forcing users to worry about adjusting max_connections and > superuser_reserved_connections to accommodate autovacuum, the system > should handle it for them. > > Were you planning on limiting the number of concurrent vacuum processes > that could be running? If so, we could probably just increase superuser > connections by that amount. If not, we might need to think of something > else... The fact that I'm currently narrowly focused on process handling means that I don't want to touch scheduling at all for now, so I'm gonna make it so that the launcher decides to launch a worker run only when no other worker is running. Thus only a single vacuum "thread" at any time. In the meantime you're welcome to think on the possible solutions to that problem, which we'll have to attack at some point in the (hopefully) near future ;-) -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings