From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | daveg <daveg(at)sonic(dot)net> |
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 23:38:28 |
Message-ID: | 17908.1312501108@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ahh ... you know what, never mind about stack traces, let's just see if
the attached patch doesn't fix it.
I still haven't reproduced the behavior here, but I think I see what
must be happening: we are getting an sinval reset while attempting to
open pg_class_oid_index. The latter condition causes its refcount to
be above 1, which will cause RelationClearRelation to directly call
RelationReloadIndexInfo, which enables the following sequence of calls:
RelationCacheInvalidate -> RelationClearRelation -> RelationReloadIndexInfo.
And the problem is that RelationCacheInvalidate intentionally forces
pg_class_oid_index to be updated first. That was okay when the code was
written, because the relcache entry for pg_class itself never really
needed any updates. Now it does, so we have to make sure pg_class gets
updated first, *then* pg_class_oid_index (which might result in a
seqscan of pg_class), then everything else (for which we'll try to use
pg_class_oid_index to locate their pg_class tuples).
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
relcache-rebuild-order.patch | text/x-patch | 1.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-08-04 23:52:45 | Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https |
Previous Message | Alex Hunsaker | 2011-08-04 22:46:21 | Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https |