I wrote: > "Dave Hartwig" <[EMAIL PROTECTED]> writes: >> LOG: next transaction ID: 884736; next OID: 306834 >> PANIC: could not access status of transaction 884736 >> DETAIL: could not read from file >> "/usr/local/pgsql8b3/data/pg_clog/0000" at offset 221184: Success >> LOG: startup process (PID 17774) was terminated by signal 6 >> LOG: aborting startup due to startup process failure
> Hmm ... do we have a problem when the next XID is exactly at a page > boundary? I'll look into that. Indeed, this is a bug I introduced into 8.0 awhile back :-(. Many thanks for the trouble report. > IIRC, pg_resetxlog doesn't have any provision to create new pg_clog > segments. Which is probably an oversight, but it's easy enough to > do it by hand. Do something like > dd bs=8k count=1 </dev/zero >/usr/local/pgsql8b3/data/pg_clog/0001 > and everything should be fine. There isn't any need to change pg_resetxlog, since the postmaster can handle creating new segments at need. But I'd modified StartupCLOG in a way that assumed the current clog page already exists, which is wrong in this boundary case. Fixed for RC3. In the meantime, creating an all-zeroes page as per the above suggestion should get you out of trouble. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org