Re: [WIP] Add relminxid column to pg_class

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> The proper interpretation of the pg_database columns
>> is that we guarantee that all XID's in the database are *at least* thus-
>> and-so, not that the minimum is exact.

> Ah-ha, an easier approach.  This would mean either:
> a) we need to seqscan pg_class each time to discover the minimum

We'd have to do that during each VACUUM to see if we could change the
pg_database entry, I think.

> b) we need a partial index on pg_class (relminxid) WHERE relkind = 'r'
> to quickly discover the minimum
> (Is the bootstrap mode able to create partial indexes?)

No, and we can't update them on system catalogs either, so it's not
gonna work.  (I think plain tables are a large enough fraction of
pg_class that you'd not save anything anyway...)

> We need to do this after each vacuum.

> We could arrange things so that autovacuum manages to do it only once
> after processing a database instead of once per table, but this could be
> fragile if the vacuuming dies partway through.

No, it'd just mean that the pg_database entry is smaller than it could
be, but this is not a failure case.  Note that a plain manual
full-database VACUUM could have the same optimization; it's not only
autovac.

> This reminds me of an unrelated problem.  On pgsql-bugs or
> pgsql-es-ayuda there was a report recently that autovacuum was dying
> because of corrupt data on a database.  The problem was that this
> prevented vacuuming of all other databases as well, because on the next
> autovacuum iteration the same database would be chosen and the same
> error would ensue.  Probably we should do something about this, so that
> autovac is allowed to process other databases before failing again on
> the offending database.

Hm, I kinda thought we had already got some provision in there to
discourage autovac from choosing the same database over and over.

            regards, tom lane