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
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

Reply via email to