"Simon Riggs" <simon@2ndquadrant.com> writes:
> [ patch to remove logId/logSeg from pg_control ]
Looking this over, I realize that there's an unresolved problem.
Although it's true that xlog.c itself doesn't use the logId/logSeg
fields for anything interesting, pg_resetxlog relies on them to
determine how far the old WAL extends, so that it can determine a
safely higher start address for the new WAL. This puts a damper
both on my thought of removing the fields altogether, and on Simon's
earlier proposal to update them in shared memory but not immediately
write pg_control during a segment switch.
The proposed patch uses pg_control's last checkpoint location to
drive the end-of-WAL computation, but that is obviously not good
enough, as WAL might have gone many segments beyond that.
Now, underestimating the WAL end address is not fatal; AFAIK the
only consequence would be some complaints about "xlog flush request is
not satisfied" until we had managed to advance the end of WAL past the
largest page LSN present in the data files. But it's still annoying.
What I'm considering is having pg_resetxlog scan the pg_xlog directory
and assume that any segment files present might have been used.
Thoughts?
regards, tom lane
