| 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: | Whole Thread | Raw Message | 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
| 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 |