Re: BUG #13523: Unexplained deadlocks (possible race condition)
От | Jack Douglas |
---|---|
Тема | Re: BUG #13523: Unexplained deadlocks (possible race condition) |
Дата | |
Msg-id | 015301d0caa0$f868f2f0$e93ad8d0$@douglastechnology.co.uk обсуждение исходный текст |
Ответ на | Re: BUG #13523: Unexplained deadlocks (possible race condition) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #13523: Unexplained deadlocks (possible race
condition)
|
Список | pgsql-bugs |
> There have been discussions of reimplementing SQL-language functions so that parsing occurs one statement at a time, but don't hold your breath about something happening in that direction; it doesn't seem to be a high priority concern for anybody. Perhaps it is worth considering a less drastic change if that is not on the cards in the immediate future? 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.
В списке pgsql-bugs по дате отправления: