Reece Hart <[EMAIL PROTECTED]> writes: > After a system crash, postgresql 8.1.4 restarted but reported that I > have an apparent wraparound:
> ... > 2006-07-13 14:03:40 PDT [10092] LOG: next MultiXactId: 5475264; next > MultiXactOffset: 13765525 > ... > 2006-07-13 14:03:40 PDT [10092] LOG: could not truncate directory > "pg_multixact/offsets": apparent wraparound > 2006-07-13 14:03:40 PDT [10092] LOG: could not truncate directory > "pg_multixact/members": apparent wraparound > There are two files left in pg_multixact: > -rw------- 1 postgres postgres 16K 2006-07-13 14:13 > pg_multixact/members/00D2 > -rw------- 1 postgres postgres 144K 2006-07-13 14:13 > pg_multixact/offsets/0053 That's odd. Those files correspond to the next MultiXactId and MultiXactOffset, so there shouldn't have been any such complaint. [ looks at code... ] I wonder if this is happening because shared->latest_page_number hasn't been set up yet when we do the end-of-recovery checkpoint. > In > http://www.mail-archive.com/pgsql-general@postgresql.org/msg76635.html > Tom Lane implies that I can probably ignore these messages. No, I was saying that the "invalid server process ID -1" was harmless. The "apparent wraparound" is a distinct issue, and I'd ask you the same question I asked Thomas: do you continue to get those log messages during subsequent checkpoints? 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
