Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > I just noticed a problem, which is why I labeled it a WIP: the current
> > implementation turns pg_database.datminxid to InvalidTransactionId when
> > the table that has the minimum relminxid is dropped.
>
> I'd argue that you should do nothing, ie, dropping a table should never
> affect datminxid. 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
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?)
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.
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.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.