Re: Truncate in synchronous logical replication failed
От | Japin Li |
---|---|
Тема | Re: Truncate in synchronous logical replication failed |
Дата | |
Msg-id | MEYP282MB1669E5CFB5FF5019C7B8977DB6749@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM обсуждение исходный текст |
Ответ на | RE: Truncate in synchronous logical replication failed ("tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>) |
Ответы |
Re: Truncate in synchronous logical replication failed
|
Список | pgsql-hackers |
On Wed, 07 Apr 2021 at 16:34, tanghy.fnst@fujitsu.com <tanghy.fnst@fujitsu.com> wrote: > On Wednesday, April 7, 2021 5:28 PM Amit Kapila <amit.kapila16@gmail.com> wrote > >>Can you please check if the behavior is the same for PG-13? This is >>just to ensure that we have not introduced any bug in PG-14. > > Yes, same failure happens at PG-13, too. > I found that when we truncate a table in synchronous logical replication, LockAcquireExtended() [1] will try to take a lock via fast path and it failed (FastPathStrongRelationLocks->count[fasthashcode] = 1). However, it can acquire the lock when in asynchronous logical replication. I'm not familiar with the locks, any suggestions? What the difference between sync and async logical replication for locks? [1] if (EligibleForRelationFastPath(locktag, lockmode) && FastPathLocalUseCount < FP_LOCK_SLOTS_PER_BACKEND) { uint32 fasthashcode = FastPathStrongLockHashPartition(hashcode); bool acquired; /* * LWLockAcquire acts as a memory sequencing point, so it's safe to * assume that any strong locker whose increment to * FastPathStrongRelationLocks->counts becomes visible after we test * it has yet to begin to transfer fast-path locks. */ LWLockAcquire(&MyProc->fpInfoLock, LW_EXCLUSIVE); if (FastPathStrongRelationLocks->count[fasthashcode] != 0) acquired = false; else acquired = FastPathGrantRelationLock(locktag->locktag_field2, lockmode); LWLockRelease(&MyProc->fpInfoLock); if (acquired) { /* * The locallock might contain stale pointers to some old shared * objects; we MUST reset these to null before considering the * lock to be acquired via fast-path. */ locallock->lock = NULL; locallock->proclock = NULL; GrantLockLocal(locallock, owner); return LOCKACQUIRE_OK; } } -- Regrads, Japin Li. ChengDu WenWu Information Technology Co.,Ltd.
В списке pgsql-hackers по дате отправления: