From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marc Munro <marc(at)bloodnok(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Index corruption |
Date: | 2006-06-30 14:04:38 |
Message-ID: | 23465.1151676278@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I trawled through the first, larger dump you sent me, and found multiple
index entries pointing to quite a few heap tuples:
Occurrences block item
2 43961 1
2 43961 2
2 43961 3
2 43961 4
2 43961 5
2 43961 6
2 43961 7
2 43961 8
2 43961 9
2 119695 1
2 119695 2
2 119695 3
2 126029 1
2 126029 2
2 126029 3
2 166694 1
2 166865 1
2 166865 2
2 166865 3
2 166865 4
2 166865 5
2 166865 6
2 166865 7
2 206221 1
2 247123 1
2 327775 1
2 327775 2
2 327775 3
2 327775 4
2 327775 5
2 327775 6
2 327775 7
2 327775 8
2 327775 9
2 327775 10
2 327775 11
Both indexes show identical sets of duplicates, which makes it pretty
hard to credit that it's a within-index problem.
You mentioned that the test had been allowed to run for a good while
after the first slave error was noted. So it seems there's no question
that we are looking at some mechanism that allows the first few entries
on a heap page to be lost and overwritten :-(, and that this happened
several times over the course of the larger run.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2006-06-30 14:44:07 | Re: Index corruption |
Previous Message | Tom Lane | 2006-06-30 13:55:54 | Re: Index corruption |