Re: Conflict detection for update_deleted in logical replication
От | Tom Lane |
---|---|
Тема | Re: Conflict detection for update_deleted in logical replication |
Дата | |
Msg-id | 334468.1757280992@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | RE: Conflict detection for update_deleted in logical replication ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>) |
Ответы |
Re: Conflict detection for update_deleted in logical replication
|
Список | pgsql-hackers |
Coverity is not happy with commit a850be2fe: /srv/coverity/git/pgsql-git/postgresql/src/backend/replication/logical/worker.c: 3276 in FindDeletedTupleInLocalRel() 3270 * maybe_advance_nonremovable_xid() for details). 3271 */ 3272 LWLockAcquire(LogicalRepWorkerLock, LW_SHARED); 3273 leader = logicalrep_worker_find(MyLogicalRepWorker->subid, 3274 InvalidOid, false); 3275 >>> CID 1665367: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "&leader->relmutex" when calling "tas". 3276 SpinLockAcquire(&leader->relmutex); 3277 oldestxmin = leader->oldest_nonremovable_xid; 3278 SpinLockRelease(&leader->relmutex); 3279 LWLockRelease(LogicalRepWorkerLock); 3280 } I think Coverity has a point. AFAICS every other call of logicalrep_worker_find() guards against a NULL result, so why is it okay for this one to dump core on NULL? regards, tom lane
В списке pgsql-hackers по дате отправления: