From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | lec <limec(at)streamyx(dot)com> |
Cc: | Scott Marlowe <smarlowe(at)qwest(dot)net>, Alvaro Herrera Munoz <alvherre(at)dcc(dot)uchile(dot)cl>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Losing records when server hang |
Date: | 2004-08-09 16:03:19 |
Message-ID: | 15482.1092067399@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
lec <limec(at)streamyx(dot)com> writes:
> It's a SCSI, RAID-5 on a Dell server.
> The hardware actually "hang". The Dell engineers came and replaced the
> motherboard but couldn't tell what the actual fault was.
> Commit as in 'COMMIT'. 'Records' 1,2,3,4,5,6,7,8,9,10 are actually
> transactions. I'm as puzzled as to why I lost the transactions in the
> middle but got the last transaction.
I'm puzzled too. I don't suppose you have the postmaster log from when
it was trying to recover from the crash? Or even better, copies of the
WAL files?
A possible theory has to do with corruption of the WAL log. For
instance, transactions 1-10 are all down to disk in WAL (or at least the
kernel told postgres the writes were done) and for one reason or another
the buffer manager chances to flush the page containing record 10 out
to its data file before the other records' pages. Now the system hangs.
After reboot, if the WAL log is unreadable beyond transaction 1 then the
database would come up with transaction 1 replayed, 2-10 not replayed,
but 10's data is out there anyway.
However this would seem to imply disk drive misfeasance above and beyond
your motherboard problem.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Guy Fraser | 2004-08-09 16:06:12 | Re: RFC: array literal syntax |
Previous Message | Robby Russell | 2004-08-09 15:31:19 | Re: Stored Procedure - Iam totally lost! |