Re: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 1741
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Erik Rijkers <er@xs4all.nl>, pgsql-hackers@postgresql.org
Date: 2012-05-30T18:52:46Z
Lists: pgsql-hackers
On Wed, May 30, 2012 at 1:47 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> 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. Ah. The problem is that FastPathTag() expects that locks on database objects will only be taken by backends with a non-zero value for MyDatabaseId. Apparently the can-i-use-the-fastpath test and the do-i-need-to-force-other-people-out-of-the-fastpath test need to be a bit more asymmetrical than they are at present. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company