Thread: WIP patch for tuple freezing issues
Attached is a draft patch for the WAL-and-freezing issues we've been
discussing. This incorporates Heikki and Simon's work on providing
WAL-logging for tuple freezing actions and pg_clog truncation
respectively, and adds on several other things:
* replace logic for when to truncate pg_clog, as discussed: it's now
driven off the system-wide minimum relfrozenxid.
* add GUC variables and pg_autovacuum support to control the freeze
distance (how far back a VACUUM sets its freeze cutoff, which becomes
the table's new relfrozenxid) as well as the freeze limit (the age of
relfrozenxid at which we force an autovacuum cycle).
* revise the autovacuum logic to exploit the per-table tracking of
relfrozenxid better: there is no concept of a "database wide autovacuum"
anymore, rather we make table-by-table decisions about what needs to
be vacuumed.
* revise the mechanism for forcing autovacs when the freeze limit is
exceeded --- this was previously checked only on completion of a VACUUM,
which seems a bit untrustworthy (if you're not vacuuming, it won't
help). I moved the functionality to varsup.c instead, where we already
had the forced-shutdown-before-wraparound code.
The patch is not ready to apply because it needs more testing (anyone
want to help?) and because I need to do more documentation work;
maintenance.sgml and the vacuum ref page both need some TLC.
Comments?
regards, tom lane
Attachment
Tom Lane wrote: > Attached is a draft patch for the WAL-and-freezing issues we've been > discussing. This incorporates Heikki and Simon's work on providing > WAL-logging for tuple freezing actions and pg_clog truncation > respectively, and adds on several other things: Looks good. Just a few notes: The patch seems to make VACUUM FULL FREEZE combination valid again, which should be note in the docs. This comment in vacuum.c: /* * If we froze any tuples, mark the buffer dirty, and write a WAL * record recording the changes. We must log the changes to be * crash-safe if we truncate clog at conclusion of the vacuum. */ is not accurate. As discussed earlier, a crash is a problem even if clog is not truncated by this vacuum, because relfrozenxid is updated anyway. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> The patch seems to make VACUUM FULL FREEZE combination valid again,
> which should be note in the docs.
Right, I haven't gotten around to fixing the VACUUM ref page yet but
this change is needed. This is really fallout from Alvaro's previous
changes BTW: there is no longer any need for VACUUM FREEZE to try to
absolutely guarantee a fully-frozen table state. All it is really doing
is guaranteeing there's nothing older than OldestXmin in there, and so
the fact that VACUUM FULL would put its own xid into the table isn't
a contradiction anymore.
BTW, I intend to say that FREEZE is deprecated in favor of the
equivalent of running VACUUM with vacuum_freeze_distance set to 0.
I'd like to remove it in 8.3 so as to get rid of one non-spec
reserved word. Any objections?
> This comment in vacuum.c:
> /*
> * If we froze any tuples, mark the buffer dirty, and write a WAL
> * record recording the changes. We must log the changes to be
> * crash-safe if we truncate clog at conclusion of the vacuum.
> */
> is not accurate.
OK, how about "... crash-safe against future truncation of clog."?
regards, tom lane