Re: autovacuum, reloptions, and hardcoded pg_class tupdesc

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> So I've been progressing on revising the autovacuum patch to make it
> work with the current reloptions. We have a number of options:

> 1. Call heap_open() for every relation that we're going to check, and
> examine the reloptions via the relcache.
> I'm not sure that I like this very much.

I don't like it at all, mainly because it implies taking locks on tables
that autovacuum doesn't need to be touching. Even if it's only
AccessShareLock, it could result in problems vis-a-vis clients that are
holding exclusive table locks.

> Right now we just plow
> ahead using a pg_class seqscan, which avoids locking the relations
> just for the sake of verifying whether they need work.

We should stick with that, and refactor the reloptions code as needed to
be able to work from just a pg_class tuple. I'm envisioning a scheme
like:

bottom level: extract from pg_class tuple, return a palloc'd struct

relcache: logic to cache the result of the above

top level: exported function to return a cached options struct

The autovac scan could use the bottom-level API.

regards, tom lane