Re: Autovacuum integration - Mailing list pgsql-patches

On Fri, Jul 08, 2005 at 03:56:25PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > Here is a second attempt at autovacuum integration.
>
> A few comments:

Excellent, thanks.  I'll be working on fixing all these.

> * I strongly disagree with keeping updatable state in a catalog.  In the
> first place, that will cause autovac itself to create vacuumable trash.

Yes, I thought about that too.  I think the argument that convinced me
to do otherwise was the possibility of messages being lost in the path
to stat collector.  And I thought that it would be possible to change
tuples in-place, like vacuum does for pg_class.  I don't have a problem
with changing it though.

The initdb-forcing point is a good one, didn't think of it.

> pg_autovacuum should only contain user-settable parameters --- which is
> still putting us at nontrivial risk for initdb constraints, but it's way
> better than internal state.  If you do that, then pg_autovacuum need
> only contain entries for tables that have been given non-default
> parameter settings.

Ok.  Do you think it's worth the trouble to have ALTER TABLE commands to
change autovac parameters?

> * The signal processing needs re-work; you can't just randomly assign
> signal numbers, you need to keep these things largely consistent with
> the other subprocesses.

I think I copied this from pgarch.c, which I can see was a really bad
idea.  Will fix.

> * I see you have an autovac_init function to "annoy the user", but
> shouldn't this be checked every time we are about to spawn an autovac
> process?

You argued exactly the other way around to Matthew, before 8.0 freeze.
Personally I don't care either way.


> * I don't see any special checks for shared catalogs, which means they
> are probably going to be over-vacuumed; or possibly under-vacuumed if
> you fail to track the update stats for them in a single place rather
> than in each database.  It'd probably be a good idea to nominate just
> one database to be the place from which shared catalogs are vacuumed;
> or treat them as a completely separate special case.

Yeah.  The problem with this is that any particular database could be
absent from the stat hash.  Personally I think we should make the stat
system aware of all databases, whether there has been activity in them
or not.  That'd make this problem moot, and we could skip those tables
in any databases except template1.


Anything I omitted I agree with, so I'll fix things up accordingly.

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"The Gord often wonders why people threaten never to come back after they've
been told never to return" (www.actsofgord.com)