Thread: Error restarting postmaster
Yesterday, one of the (replicated) remote databases I work with somehow got corrupted, so I attempted to drop a new copy off of the master (on a different box) and rebuild the database. Creation, language install, schema reload, all appeared to go well. On the actual data reload, I set the system aside and went on to something else, as the db takes a while to load. I came back to discover that the connection between my system and the one where the db was being rebuilt had been severed. Opening a new remote connection, I went in and attempted to rebuild the database, only to discover that neither postgres nor the postmaster was running. And when I attempted to restart the postmaster process, I received the following error:
postgres@district20:/usr/local/pgsql/bin> ./postmaster -D /usr/local/pgsql/data/
LOG: database system was interrupted while in recovery at 2007-07-31 08:17:22 CDT
HINT: This probably means that some data is corrupted and you will have to use the last backup for recovery.
LOG: checkpoint record is at 3C/D7008078
LOG: redo record is at 3C/D7008078; undo record is at 0/0; shutdown FALSE
LOG: next transaction ID: 59170527; next OID: 532878
LOG: next MultiXactId: 1; next MultiXactOffset: 0
LOG: database system was not properly shut down; automatic recovery in progress
LOG: redo starts at 3C/D70080BC
PANIC: block 39 unfound
WARNING: autovacuum not started because of misconfiguration
HINT: Enable options "stats_start_collector" and "stats_row_level".
LOG: startup process (PID 6403) was terminated by signal 6
LOG: aborting startup due to startup process failure
LOG: database system was interrupted while in recovery at 2007-07-31 08:17:22 CDT
HINT: This probably means that some data is corrupted and you will have to use the last backup for recovery.
LOG: checkpoint record is at 3C/D7008078
LOG: redo record is at 3C/D7008078; undo record is at 0/0; shutdown FALSE
LOG: next transaction ID: 59170527; next OID: 532878
LOG: next MultiXactId: 1; next MultiXactOffset: 0
LOG: database system was not properly shut down; automatic recovery in progress
LOG: redo starts at 3C/D70080BC
PANIC: block 39 unfound
WARNING: autovacuum not started because of misconfiguration
HINT: Enable options "stats_start_collector" and "stats_row_level".
LOG: startup process (PID 6403) was terminated by signal 6
LOG: aborting startup due to startup process failure
A google search on the Panic clause lead me to an old thread in the [Hackers] list, which looks like it was a similar problem, but I can't figure out from that thread how the problem was solved. Would someone please help me figure out what I need to do to correct this and get my database running again?
Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us.
Andrew Edson <cheighlund@yahoo.com> writes: > PANIC: block 39 unfound > LOG: startup process (PID 6403) was terminated by signal 6 > LOG: aborting startup due to startup process failure What PG version is this? (If your answer had a release date more than about a year ago, first update to the latest release in that branch and see if that fixes it.) regards, tom lane
Is somewhat old, 8.1.3. I'll try to upgrade it to the 8.1.9. The box is running on SuSE 9.2, if I recall correctly...which binary rpm should I snag for that?
Tom Lane <tgl@sss.pgh.pa.us> wrote:
Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV.
Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andrew Edson writes:
> PANIC: block 39 unfound
> LOG: startup process (PID 6403) was terminated by signal 6
> LOG: aborting startup due to startup process failure
What PG version is this?
(If your answer had a release date more than about a year ago, first
update to the latest release in that branch and see if that fixes it.)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV.
On Tue, 2007-07-31 at 06:53 -0700, Andrew Edson wrote: > Yesterday, one of the (replicated) remote databases I work with > somehow got corrupted, so I attempted to drop a new copy off of the > master (on a different box) and rebuild the database. Creation, > language install, schema reload, all appeared to go well. On the > actual data reload, I set the system aside and went on to something > else, as the db takes a while to load. I came back to discover that > the connection between my system and the one where the db was being > rebuilt had been severed. Opening a new remote connection, I went in > and attempted to rebuild the database, only to discover that neither > postgres nor the postmaster was running. And when I attempted to > restart the postmaster process, I received the following error: > > postgres@district20:/usr/local/pgsql/bin> ./postmaster > -D /usr/local/pgsql/data/ > LOG: database system was interrupted while in recovery at 2007-07-31 > 08:17:22 CDT > HINT: This probably means that some data is corrupted and you will > have to use the last backup for recovery. > LOG: checkpoint record is at 3C/D7008078 > LOG: redo record is at 3C/D7008078; undo record is at 0/0; shutdown > FALSE > LOG: next transaction ID: 59170527; next OID: 532878 > LOG: next MultiXactId: 1; next MultiXactOffset: 0 > LOG: database system was not properly shut down; automatic recovery > in progress > LOG: redo starts at 3C/D70080BC > PANIC: block 39 unfound > WARNING: autovacuum not started because of misconfiguration > HINT: Enable options "stats_start_collector" and "stats_row_level". > LOG: startup process (PID 6403) was terminated by signal 6 > LOG: aborting startup due to startup process failure > > A google search on the Panic clause lead me to an old thread in the > [Hackers] list, which looks like it was a similar problem, but I can't > figure out from that thread how the problem was solved. Would someone > please help me figure out what I need to do to correct this and get my > database running again? You're running 8.1 with GIST indexes and you will prefer the way they work in 8.2. The changes were bug fixes but possibly considered extensive enough to not have been backpatched. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com