| From: | daveg <daveg(at)sonic(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: error: could not find pg_class tuple for index 2662 |
| Date: | 2011-08-04 09:04:42 |
| Message-ID: | 20110804090442.GF14353@sonic.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Aug 03, 2011 at 11:18:20AM -0400, Tom Lane wrote:
> Evidently not, if it's not logging anything, but now the question is
> why. One possibility is that for some reason RelationGetNumberOfBlocks
> is persistently lying about the file size. (We've seen kernel bugs
> before that resulted in transiently wrong values, so this isn't totally
> beyond the realm of possibility.) Please try the attached patch, which
> extends the previous one to add a summary line including the number of
> blocks physically scanned by the seqscan.
Ok, I have results from the latest patch and have attached a redacted
server log with the select relfilenode output added inline. This is the
shorter of the logs and shows the sequence pretty clearly. I have additional
logs if wanted.
Summary: the failing process reads 0 rows from 0 blocks from the OLD
relfilenode.
-dg
--
David Gould daveg(at)sonic(dot)net 510 536 1443 510 282 0869
If simplicity worked, the world would be overrun with insects.
| Attachment | Content-Type | Size |
|---|---|---|
| c27.log | text/plain | 5.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Boszormenyi Zoltan | 2011-08-04 09:10:01 | Re: SYNONYMS (again) |
| Previous Message | Dean Rasheed | 2011-08-04 08:55:43 | Re: cataloguing NOT NULL constraints |