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 по дате отправления: