Re: Problem with starting PostgreSQL server 7.4.19

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: Kakoli Sen <kakolis(at)cdacb(dot)ernet(dot)in>, pgsql-general(at)postgresql(dot)org
Subject: Re: Problem with starting PostgreSQL server 7.4.19
Date: 2008-03-12 06:02:34
Message-ID: 13104.1205301754@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> writes:
> Kakoli Sen wrote:
>> 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' ?

Certainly not good practice, but theoretically PG should be proof
against even such deliberate abuse as that.

What seemed odd to me was

>> 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

Experimentation shows that a freshly initialized 7.4 database has
WAL locations like this:

Latest checkpoint location: 0/9DFCF0
Prior checkpoint location: 0/9D92C0

so either you'd only ever thrown a few kilobytes of stuff into the DB
or there was something seriously wrong with pg_control to begin with.
I'm wondering about mistaken filesystem restores ...

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Kakoli Sen 2008-03-12 06:07:21 Re: Problem with starting PostgreSQL server 7.4.19
Previous Message Blair Bethwaite 2008-03-12 05:53:07 SELECT overhead in explicit transaction