| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Jack Douglas <jack(at)douglastechnology(dot)co(dot)uk> |
| Cc: | 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #13523: Unexplained deadlocks (possible race condition) |
| Date: | 2015-07-30 08:38:05 |
| Message-ID: | 20150730083805.GA3161@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 2015-07-30 09:23:10 +0100, Jack Douglas wrote:
> If parsing the INSERT aquires the RowExclusiveLock, perhaps parsing the LOCK
> statement should also aquire the lock? That would mean the following
> principle in the documentation ("...The best defense against deadlocks is
> generally to avoid them by being certain that all applications using a
> database acquire locks on multiple objects in a consistent order...",
> http://www.postgresql.org/docs/9.4/static/explicit-locking.html#LOCKING-DEAD
> LOCKS) would be possible (or at least more easily understood) when using
> SQL-language functions.
I don't think that'd help at all? The problem here is the lock upgrade
from RowExclusiveLock to the exclusive lock, and that'll not be fixed by
that proposal?
Regards,
Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | marko | 2015-07-30 08:53:52 | BUG #13528: LATERAL vs. correlated scalar subquery |
| Previous Message | Jack Douglas | 2015-07-30 08:23:10 | Re: BUG #13523: Unexplained deadlocks (possible race condition) |