Alvaro Herrera <alvhe...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
