Thread: BUG #17591: elog(ERROR) cause SharedSnapshotLock deadlock

The following bug has been logged on the website:

Bug reference:      17591
Logged by:          ma liangzhu
Email address:      ma100@hotmail.com
PostgreSQL version: 14.5
Operating system:   centos7
Description:

in lock.c, we can see code  Release lock before return    , e.g.

```c
996: LockAcquireExtended
{ 
    LWLockAcquire(partitionLock, LW_EXCLUSIVE);
 
    proclock = SetupLockInTable( );
    if (!proclock)
    {     
        LWLockRelease(partitionLock);  --- Release lock before return     
        ereport(ERROR,)
    }
}
```

bug we can see some code doesn't release the lock. Does it may cause
deadlock?

```c
LockRelease()
{
    LWLockAcquire(partitionLock, LW_EXCLUSIVE);
 
    lock = locallock->lock;
    if (!lock)
    { 
        lock = (LOCK *) hash_search_with_hash_value( );
        if (!lock)
2126:            elog(ERROR, "failed to re-find shared lock object");  -- exit
without release
    }
```

PG Bug reporting form <noreply@postgresql.org> writes:
> in lock.c, we can see code  Release lock before return    , e.g.
> ...
> bug we can see some code doesn't release the lock. Does it may cause
> deadlock?

Transaction cleanup will automatically release all locks (and other
resources too).  So the places that do a manual release before
elog(ERROR) are something of a waste of code space.  It might be worth
doing that if you're concerned about holding the lock for the minimum
possible amount of time; but usually that's only a consideration for
very heavily-contended spinlocks or LWLocks.

            regards, tom lane