On Wed, May 30, 2012 at 1:07 PM, Heikki Linnakangas
<heikki.linnakangas@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