Re: NT + deadlock intended behaviour ?
От | Alvaro Herrera |
---|---|
Тема | Re: NT + deadlock intended behaviour ? |
Дата | |
Msg-id | 20040718055123.GD3449@dcc.uchile.cl обсуждение исходный текст |
Ответ на | Re: NT + deadlock intended behaviour ? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: NT + deadlock intended behaviour ?
|
Список | pgsql-hackers |
On Sun, Jul 18, 2004 at 01:38:57AM -0400, Tom Lane wrote: > Gaetano Mendola <mendola@bigfoot.com> writes: > > why SESSION 1 was unblocked ? > > ... > > Why that commit unblock the SESSION 1? > > IMHO session 1 should have been unblocked in both cases as soon as > session 2's subtransaction failed. We have always made a practice > of releasing a transaction's locks immediately upon failure. > > The reason it does not seem to act that way is that Alvaro's taken a > shortcut in WaitForTransaction: subtransactions do not take out a > separate transaction lock and so WaitForTransaction has to wait for the > top-level transaction. Your sub-COMMIT fails the outer transaction > (because the inner one is failed) and so the top transaction lock > releases at that point. In the sub-ABORT case the outer transaction > stays good and continues to hold its lock. > > I've already suggested that this shortcut is no good, and now I'm > pretty sure of it ... FYI, this is no longer the case with the savepoints patch I just posted. It's too late here to check if this solves Gaetano concerns. Gaetano, please apply the latest savepoints patch (savepoint-5.patch) and let me know how it goes ... -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "Ni aun el genio muy grande llegaría muy lejos si tuviera que sacarlo todo de su propio interior" (Goethe)
В списке pgsql-hackers по дате отправления: