Re: Problem with starting PostgreSQL server 7.4.19

From: "Kakoli Sen" <kakolis(at)cdacb(dot)ernet(dot)in>
To: "Craig Ringer" <craig(at)postnewspapers(dot)com(dot)au>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: Problem with starting PostgreSQL server 7.4.19
Date: 2008-03-12 06:07:21
Message-ID: IAEGJAMPJBBOGKLOGJADEEGBCCAA.kakolis@cdacb.ernet.in
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,
Actually, I tried stopping server by 'kill `cat
/opt/pgsql/data/postmaster.pid`. This did not work. So I used kill -9 on Red
Hat 4.

This is a test database where we are in the process of setting up. So it
does not have live data. Still I do agree, it was not a good idea.

Now, do I have to re-install PostgreSQL or is there any way out?

Server configuration is default. Only change from default is allowing tcp/ip
connections.

Regards,

Kakoli

> -----Original Message-----
> From: pgsql-general-owner(at)postgresql(dot)org
> [mailto:pgsql-general-owner(at)postgresql(dot)org]On Behalf Of Craig Ringer
> Sent: Wednesday, March 12, 2008 11:09 AM
> To: Kakoli Sen
> Cc: pgsql-general(at)postgresql(dot)org
> Subject: Re: [GENERAL] Problem with starting PostgreSQL server 7.4.19
>
>
> Kakoli Sen wrote:
> > Hello all,
> > It was running fine initially and the database was
> lying idle for a
> > few days. Today I looged into the machine and restarted the server by
> > killing the process by 'kill -9 pid'. And then restarted it by
> > 'postmaster -i -D /opt/pgsql/data/'.
> >
> Why did you use `kill -9' ? Was it not responding to `kill -15' ( ie
> SIGTERM, kill -TERM ) or shutdown using the init script?
>
> SIGKILL, ie signal 9, terminates the process without giving it a chance
> to clean its state up. It gets no chance to write out buffered data,
> mark data files as clean, or take any other safe shutdown actions. It's
> a REALLY REALLY BAD IDEA to do this on a database server, though it
> should still be able to recover if it's configured to operate with fsync
> enabled etc.
> > Then it gives the following error on stdout :
> >
> > LOG: database system was interrupted at 2008-03-06 14:15:17 IST
> > LOG: record with incorrect prev-link 1/0 at 0/A4EB08
> > LOG: invalid primary checkpoint record
> > LOG: record with incorrect prev-link 42FD/0 at 0/A4EAC8
> > LOG: invalid secondary checkpoint record
> > PANIC: could not locate a valid checkpoint record
> Ouch. It can't handle either of the checkpoints, and so it can't load
> the database.
>
> I don't know what database repair tools exist, but personally at this
> point I'd be glad my backups are always kept up to date.
> > What is the problem? It was running fine all this time.
> >
> I suspect that killing it without giving it a chance to do any cleanup
> operations might not have helped.
>
> What's your server configuration? Could you have disabled any safe I/O
> options to get some more speed out of the database, perhaps?
>
> I'm pretty sure 8.x copes with SIGKILL (because of its use of WAL
> logging, strong fsync requirements, etc) though of course it's still not
> a good idea. I don't know about 7.x .
>
> --
> Craig Ringer
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2008-03-12 06:10:39 Re: SELECT overhead in explicit transaction
Previous Message Tom Lane 2008-03-12 06:02:34 Re: Problem with starting PostgreSQL server 7.4.19