"Simon Riggs" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match