Re: autovacuum process handling

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.