Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Jun 19, 2011 at 5:13 PM, Simon Riggs <simon@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.GF21098@tornado.leadboat.com
regards, tom lane
