From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Dave Hartwig" <daveh(at)Routescape(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Can't Restart ver 8.0b3 |
Date: | 2004-12-22 18:50:12 |
Message-ID: | 6304.1103741412@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> "Dave Hartwig" <daveh(at)Routescape(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-12-22 21:03:21 | Re: Bgwriter behavior |
Previous Message | Dave Hartwig | 2004-12-22 18:25:38 | Re: Can't Restart ver 8.0b3 |