Re: Problem with starting PostgreSQL server 7.4.19 - Mailing list pgsql-general

From Kakoli Sen
Subject Re: Problem with starting PostgreSQL server 7.4.19
Date
Msg-id IAEGJAMPJBBOGKLOGJADEEGBCCAA.kakolis@cdacb.ernet.in
Whole thread Raw
In response to Re: Problem with starting PostgreSQL server 7.4.19  (Craig Ringer <craig@postnewspapers.com.au>)
Responses Re: Problem with starting PostgreSQL server 7.4.19  (Craig Ringer <craig@postnewspapers.com.au>)
Re: Problem with starting PostgreSQL server 7.4.19  (Tom Lane <tgl@sss.pgh.pa.us>)
Problem with GRANT in 7.4.19  ("Kakoli Sen" <kakolis@cdacb.ernet.in>)
List 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@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Craig Ringer
> Sent: Wednesday, March 12, 2008 11:09 AM
> To: Kakoli Sen
> Cc: pgsql-general@postgresql.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@postgresql.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.

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Problem with starting PostgreSQL server 7.4.19
Next
From: Tom Lane
Date:
Subject: Re: SELECT overhead in explicit transaction