Re: Conflict detection for update_deleted in logical replication - Mailing list 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