| From: | Daniel Farina <daniel(at)heroku(dot)com> |
|---|---|
| To: | Klaus Ita <klaus(at)worstofall(dot)com> |
| Cc: | Maciek Sakrejda <maciek(at)heroku(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #8347: PANIC: heap_insert_redo: failed to add tuple when applying WAL |
| Date: | 2013-08-02 08:05:19 |
| Message-ID: | CAAZKuFZEEFNVywTVk4CKXbT2j9D0FrCUM6s-zooiDgYURk4dxQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Aug 2, 2013 at 12:51 AM, Klaus Ita <klaus(at)worstofall(dot)com> wrote:
> Isn't it a funny coincidence, that we also had a corruption of that
> same/similar type?
>
> my disk was quite confidently not tampered. I am wondering: Does PG sign, or
> checksum wal_files? Is the integrity of wal_files ensured by any mechanism?
> Because if it IS, then - in our case - it's a corruption caused BY the
> postgres master server. I can replay the wal's and re-create the same error
> over and over.
Corruption can hitch a ride on a WAL full page image without much
difficulty, as long as the page header looks legit (from what I've
seen so far, a bad page header will prevent the system from doing much
with it, so no FPIs will be generated).
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Albe Laurenz | 2013-08-02 08:22:47 | Re: Recovery_target_time misinterpreted? |
| Previous Message | Klaus Ita | 2013-08-02 07:51:34 | Re: BUG #8347: PANIC: heap_insert_redo: failed to add tuple when applying WAL |