Thread: Control File Context is Broken

Hi there,

I'm a newbie at PostgreSQL but as I'm administering a server that runs it I
figured this would be the best list to send my question to.  The server is a
cobalt RaQ4 running Red Hat Linux.

Here is the problem:

The cobalt system stores critical data in a PostgreSQL database.  Earlier
today functions using PostgreSQL went offline and upon exploration I
realized that the postgresql server could not initialize.  When I try to
start postgresql - via /etc/rc.d/init.d/postgresql start - I'm given an
error message reading: "Setting up PostgreSQL: failed!"  I checked the log
files and there are a handful of the following errors in it:

020111.16:00:01.144 [7651] DEBUG: Data Base System is starting up at Fri Jan
11 16:00:01 2002
020111.16:00:01.144 [7651] FATAL 2: Control file context is broken
020111.16:00:01.144 [7651] FATAL 2: Control file context is broken
Startup failed - abort
020111.16:06:44.496 [8391] DEBUG: Data Base System is starting up at Fri Jan
11 16:06:44 2002
020111.16:06:44.496 [8391] FATAL 2: Control file context is broken
020111.16:06:44.496 [8391] FATAL 2: Control file context is broken
Startup failed - abort

I figured I'd try and activate the postmaster, back up the DB, and try
creating a new one.  However, postmaster would not launch either, and I was
prompted with the same error above.

I'm not quite sure what I need to do to repair this problem.  If someone
could give me some direction it would be very much appreciated!

Thanks,

Andrew

"Andrew M. Danneffel" <adanneffel@atomation.ca> writes:
> The server is a
> cobalt RaQ4 running Red Hat Linux.

A version number for Postgres would be the useful tidbit here.

> 020111.16:00:01.144 [7651] FATAL 2: Control file context is broken

This error indicates that one of three fields in pg_control has a bogus
value.  The only failures hereabouts that we've heard reported from the
field involve a silly timestamp.  Is it possible that the system clock
was set to a silly value (ie, < 1970) last time you shut down?  If so,
you could recover by commenting out the relevant check in
src/backend/access/transam/xlog.c.

            regards, tom lane