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
Date: Mon, 22 Aug 2022 09:13:38 -0400
Message-ID: <257677.1661174018@sss.pgh.pa.us> (raw)
In-Reply-To: <17591-6ae23a6598b64c4e@postgresql.org>
References: <17591-6ae23a6598b64c4e@postgresql.org>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, ma100@hotmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17591: elog(ERROR) cause SharedSnapshotLock deadlock
In-Reply-To: <257677.1661174018@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox