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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 1741
Дата
Msg-id CA+TgmoY9okf1R8Vw1-uAsXVb7LpCWw1gd27L90ekTXEH6VxO7w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 1741  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 1741  (Robert Haas <robertmhaas@gmail.com>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: Figuring out shared buffer pressure
Следующее
От: Josh Kupershmidt
Дата:
Сообщение: pg_restore logging inconsistency