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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ma100(at)hotmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17591: elog(ERROR) cause SharedSnapshotLock deadlock
Date: 2022-08-22 13:13:38
Message-ID: 257677.1661174018@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Garbuz, Yakov [ASM Research] 2022-08-22 13:16:34 Re: [External] Re: BUG #17585: Wrong path to the extension control file
Previous Message John Naylor 2022-08-22 10:52:29 Re: fetching bytea (blob) data of 850 MB from psql client failed