Re: autovacuum process handling

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 jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)