Hi,
I attach my patch adding the relminxid column to pg_class; this turns
vacuum/freeze Xid tracking a per-table issue, and so it removes the
need to vacuum whole databases. Transaction Id wraparound can thus be
dealt with one table at a time. I refer you to the old thread for a
more complete description of the patch:
http://archives.postgresql.org/pgsql-patches/2005-11/msg00074.php
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. The problem is
that this could cause "vacuum starvation" if autovacuum is using
datminxid to decide what database to vacuum, and the minimum Xid table
is being dropped continuously. I had refrained from calculating
pg_database.datminxid each time said table is dropped, because doing it
means scanning pg_class and locking pg_database -- I'm wary of deadlock
problems. Not sure what to do here. (Maybe the answer is to do nothing
-- this is a very low probability scenario anyway. Opinions?)
I dropped the controversial (and broken) idea of setting a table's
relminxid to FreezeTransactionId (which would allow a table to survive a
transaction wraparound without needing vacuum at all.) This will need
more work; probably a switch to mark a table strictly read-only.
Unless there are objections I plan to apply this probably by the next
weekend, so that there is plenty of time for review and comment.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.