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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Erik Rijkers <er(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 1741
Date: 2012-05-30 20:25:03
Message-ID: CA+TgmobJnruGwHVSTLqQ=m1hS80eKpb2w7DvgyaGC5yfJe8E+g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 30, 2012 at 2:52 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, May 30, 2012 at 1:47 PM, Robert Haas <robertmhaas(at)gmail(dot)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.

I've fixed things so that Heikki's test case now behaves as expected.
Hopefully this fixes Erik's problem as well, but I haven't tested.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-05-30 20:26:09 Re: Advisory locks seem rather broken
Previous Message Merlin Moncure 2012-05-30 20:19:20 Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile