Re: [HACKERS] pg_upgrade

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Here is a patch I need to /contrib/pg_resetxlog to support a new "-x
> XID" option to set the XID in pg_control.

I don't like this patch.  It seems weird to add -x as an independent
function rather than just have pg_resetxlog do its normal thing and
allow -x to override the xid value.  -x defined that way makes sense
in the context of pg_resetxlog's original mission (in particular, one
should be able to use it in the situation where the old pg_control is
unrecoverable).  Also, there's no good reason for pg_upgrade not to
reset the xlog --- certainly we would not want the records therein to
be replayed against the pg_upgraded database!

There is a more serious problem, also.  Pages transferred over from the
old database will contain LSN values pointing into the old xlog.  If
these are past the end of the new database's xlog (very probable) then
you have a strong risk of "XLogFlush: request past end of xlog" errors,
which per Vadim's insistence we treat as a system-wide fatal condition.

Probably the cleanest way to deal with that is to tweak pg_resetxlog
further to have an optional switch with a minimum xlog position.
It already knows how to set up its cleared xlog with a position >=
end of the removed log, so you could have an additional option switch
that forces the new position to be >= switch value.  To issue the
switch, pg_upgrade would have to look at the old xlog files to determine
the endpoint of the old xlog.  Seems messy but not impossible.

            regards, tom lane