On Fri, Jul 29, 2011 at 09:55:46AM -0400, Tom Lane wrote:
> The thing that was bizarre about the one instance in the buildfarm was
> that the error was persistent, ie, once a session had failed all its
> subsequent attempts to access pg_class failed too. I gather from Dave's
> description that it's working that way for him too. I can think of ways
> that there might be a transient race condition against a REINDEX, but
> it's very unclear why the failure would persist across multiple
> attempts. The best idea I can come up with is that the session has
> somehow cached a wrong commit status for the reindexing transaction,
> causing it to believe that both old and new copies of the index's
> pg_class row are dead ... but how could that happen? The underlying
It is definitely persistant. Once triggered the error occurs for any new
statement until the session exits.
> state in the catalog is not wrong, because no concurrent sessions are
> upset (at least not in the buildfarm case ... Dave, do you see more than
> one session doing this at a time?).
It looks like it happens to multiple sessions so far as one can tell from
the timestamps of the errors:
timestamp sessionid error------------ ------------- ----------------------------------------------03:05:37.434
4e26a861.4a6dcould not find pg_class tuple for index 266203:05:37.434 4e26a861.4a6f could not find pg_class tuple for
index2662
03:06:12.041 4e26a731.438e could not find pg_class tuple for index 2662
03:06:12.042 4e21b6a3.629b could not find pg_class tuple for index 266203:06:12.042 4e26a723.42ec could not find
pg_classtuple for index 2662 at character 13
-dg
--
David Gould daveg@sonic.net 510 536 1443 510 282 0869
If simplicity worked, the world would be overrun with insects.