On Fri, Jun 17, 2011 at 9:32 AM, simon <si...@2ndquadrant.com> wrote: > 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);
Similar to the way we lock a relation for extension, as a sub-lock of the main relation lock. Relcache rebuilds use a ShareLock, ALTER TABLE uses an ExclusiveLock. I've written the patch, just need to test later today.... gotta step out now. -- 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
