Alvaro Herrera <[EMAIL PROTECTED]> 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
> 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
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?