Re: BUG #10189: Limit in 9.3.4 no longer works when ordering using a composite multi-type index
От | Tom Lane |
---|---|
Тема | Re: BUG #10189: Limit in 9.3.4 no longer works when ordering using a composite multi-type index |
Дата | |
Msg-id | 3354.1399057710@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #10189: Limit in 9.3.4 no longer works when ordering using a composite multi-type index (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: BUG #10189: Limit in 9.3.4 no longer works when ordering
using a composite multi-type index
|
Список | pgsql-bugs |
Andres Freund <andres@2ndquadrant.com> writes: > On 2014-05-02 14:23:50 -0400, Tom Lane wrote: >> There's been one post-9.3.4 fix in this same general area: >> http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=c0bd128c8 >> but according to the commit message, at least, that bug would not have led >> to the symptom you're seeing, namely rows disappearing from indexes while >> they're still visible to seqscans. > Hm. With a bit of bad luck it might. The bug essentially has the > consequence that two updates might succeed for the same row. Consider > what happens if the row gets hot updated and then a second hot update, > due to the bug, also succeeds. The second update will change t_ctid of > the old tuple to point to the second version. If the transaction that > did the second update then aborts a index search starting at the root of > the hot change won't find any surviving tuple. But a seqscan will. :(. Hm, good point. Nick, if you're up for applying a hotfix you could try grabbing the aforesaid patch and seeing if it makes things better. If not, we're probably gonna need that test case to figure out where things are still going wrong. regards, tom lane
В списке pgsql-bugs по дате отправления: