Re: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 1741

On Wed, May 30, 2012 at 1:07 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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