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?
> 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. 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... -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
