Re: autovacuum, reloptions, and hardcoded pg_class tupdesc

Alvaro Herrera <alvherre@commandprompt.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