Skip site navigation (1) Skip section navigation (2)

Re: Can't Restart ver 8.0b3

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: (view raw, whole thread or download thread mbox)
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

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2004-12-22 21:03:21
Subject: Re: Bgwriter behavior
Previous:From: Dave HartwigDate: 2004-12-22 18:25:38
Subject: Re: Can't Restart ver 8.0b3

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group