From: Tom Lane <tgl@sss.pgh.pa.us>
To: ma100@hotmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17591: elog(ERROR) cause SharedSnapshotLock deadlock
In-reply-to: <17591-6ae23a6598b64c4e@postgresql.org>
References: <17591-6ae23a6598b64c4e@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Mon, 22 Aug 2022 06:23:59 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <257676.1661174018.1@sss.pgh.pa.us>
Date: Mon, 22 Aug 2022 09:13:38 -0400
Message-ID: <257677.1661174018@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/257677.1661174018%40sss.pgh.pa.us>
Precedence: bulk

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