On Wed, May 30, 2012 at 1:07 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > There's something wrong with the way AccessExclusiveLocks work on a standby. > I did "begin; truncate foo; -- leave the xact open" in the master, and > waited until the xlog records are shipped to the standby. Then I did this in > the standby: > > testdb=# begin; > BEGIN > testdb=# select * from foo; > id > ---- > (0 rows) > > testdb=# select locktype, database, relation, virtualtransaction, pid, mode, > granted, fastpath from pg_locks where locktype='relation' and > relation='foo'::regclass; > locktype | database | relation | virtualtransaction | pid | mode > | granted | fastpath > ----------+----------+----------+--------------------+-------+---------------------+---------+---------- > relation | 16384 | 27332 | 2/78 | 24984 | > AccessShareLock | t | t > relation | 16384 | 27332 | 1/0 | 24344 | > AccessExclusiveLock | t | f > (2 rows) > > The "select * from foo" query should have blocked, because the transaction > in the master is holding an AccessExclusiveLock on the table. > > The process holding the AccessExclusiveLock is the startup process. It's > holding the lock on behalf of the transaction in the master. But something's > wrong, and the AccessExclusiveLock doesn't stop a regular backend from > acquiring the AccessShareLock on the table. I suspect the fast-path locking > patch, because this works on 9.1.
Yeah, apparently so. gdb says that FastPathStrongRelationLocks on the standby is all-zeros even after that record has been replayed. Not sure how that's possible yet. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
