Robert Haas <robertmh...@gmail.com> writes: > On Sun, Jun 19, 2011 at 5:13 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >> We scan pg_class in two ways: to rebuild a relcache entry based on a >> relation's oid (easy fix). We also scan pg_class to resolve the name >> to oid mapping. The name to oid mapping is performed *without* a lock >> on the relation, since we don't know which relation to lock. So the >> name lookup can fail if we are in the middle of a pg_class update. >> This is an existing potential bug in Postgres unrelated to my patch.
> If this is a pre-existing bug, then it's not clear to me why we need > to do anything about it at all right now. Yeah. This behavior has been there since day zero, and there have been very few complaints about it. But note that there's only a risk for pg_class updates, not any other catalog, and there is exactly one kind of failure with very predictable consequences. The ALTER TABLE patch has greatly expanded the scope of the issue, and that *is* a regression compared to prior releases. BTW, it seems to me that this issue is closely related to what Noah is trying to fix here: http://archives.postgresql.org/message-id/20110612191843.gf21...@tornado.leadboat.com regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
