From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 8.1 index corruption woes |
Date: | 2008-07-08 01:28:17 |
Message-ID: | 27175.1215480497@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> Another point to keep in mind, if you are trying to analyze files
>> belonging to a live database, is that what you can see in the filesystem
>> may not be the "current" contents of every page. For typical access
>> patterns it'd be unsurprising for the visible index pages to lag behind
>> those of the heap, since they'd be "hotter" and tend to stay in shared
>> buffers longer.
> Hmm, I think the files come from a PITR slave that's not online. I'll
> ask to be sure.
8.1 didn't have restartpoint code, and of course bgwriter isn't running;
so I believe filesystem pages on a PITR slave could be arbitrarily far
out of date if the corresponding shared buffer got touched regularly.
Try doing the analysis on the master immediately after a CHECKPOINT
command.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | ITAGAKI Takahiro | 2008-07-08 01:29:04 | Re: [PATCHES] WIP: executor_hook for pg_stat_statements |
Previous Message | Alvaro Herrera | 2008-07-08 01:17:17 | Re: 8.1 index corruption woes |