On Thu, Jun 16, 2011 at 11:54 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> 2. In response, some other backend starts to reload its relcache entry > for pgbench_accounts when it begins its next command. It does an > indexscan with SnapshotNow on pg_class to find the updated pg_class row. > > 3. Meanwhile, some third backend commits another ALTER TABLE, updating > the pg_class row another time. Since we have removed the > AccessExclusiveLock that all variants of ALTER TABLE used to take, this > commit can happen while backend #2 is in process of scanning pg_class. This part is the core of the problem: We must not be able to update the catalog entry while a relcache rebuild scan is in place. So I'm prototyping something that allows LockRelationDefinitionOid(targetRelId, ShareLock); -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
