Alvaro Herrera <[EMAIL PROTECTED]> writes:
> In fact this seems pretty easy to do. Add a field to pg_class, tell
> VACUUM to update it using the determined freezeLimit, and that's it.
I think that it'd be worth fixing things so that the recorded value
is not the freeze cutoff value (as now), but the actual lowest
not-frozen XID present anywhere in the table. The present code does not
do that because it's painful to track across multiple tables, but on a
per-table basis it seems easy. In particular this rule allows you to
set a sane value for the pg_class field when the table is created (ie,
current transaction's XMIN, rather than a billion less).
> (Note that if we ever implement partial vacuum, it won't be able to
> update the freeze point. But that was true before anyway.)
Sure.
> We also need to teach autovacuum to update pg_database.datfreezexid,
> using the minimum from pg_class.
No, no, no. autovacuum is not a required part of the system and it's
not going to become so any time soon. Updating the pg_database entry
will have to be the responsibility of VACUUM itself. It's not that
terrible: you don't have to scan pg_class unless you see that the
pg_class.relfreezexid value you are replacing is equal to
pg_database.datfreezexid, and with the exact computation suggested
above, that won't be a common occurrence.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
