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+TgmobJnruGwHVSTLqQ=m1hS80eKpb2w7DvgyaGC5yfJe8E+g@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
|
Список | pgsql-hackers |
On Wed, May 30, 2012 at 2:52 PM, Robert Haas <robertmhaas@gmail.com> wrote: > 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. 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
В списке pgsql-hackers по дате отправления: