Re: SSI predicate locking on heap -- tuple or row?

Поиск
Список
Период
Сортировка
От Dan Ports
Тема Re: SSI predicate locking on heap -- tuple or row?
Дата
Msg-id 20110523183233.GF85637@csail.mit.edu
обсуждение исходный текст
Ответ на SSI predicate locking on heap -- tuple or row?  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: SSI predicate locking on heap -- tuple or row?
Re: SSI predicate locking on heap -- tuple or row?
Список pgsql-hackers
On Sat, May 21, 2011 at 03:09:12PM -0500, Kevin Grittner wrote:
> I went back to the example which persuaded me and took another look.  On
> review I see that this didn't prove the point because there was a
> dangerous structure with T1 as a pivot which should have caused SSI to
> break the cycle.  Since it didn't, either I got careless in my testing
> methodology (which I will recheck when I get back to Wisconsin) or there
> was a bug -- but either way, this example can't prove that the predicate
> locks need to follow the row to new versions.

I'm still working through the more general question, but I wanted to
see what was going on with this example. It appears there's a bug,
because this doesn't cause a rollback without the version linking.

Specifically, the problem is a missing check in
OnConflict_CheckForSerializationFailure. We check whether the conflict
has caused the writer to become a pivot, but only if neither the reader
or writer is committed. Why is that last condition there? In this case,
the reader (T4) has committed but the writer (T1) hasn't.

It would be worth making sure there aren't any other cases we're
missing here, although I don't see any right now.

Dan

-- 
Dan R. K. Ports              MIT CSAIL                http://drkp.net/


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: sepgsql: fix relkind handling on foreign tables
Следующее
От: Noah Misch
Дата:
Сообщение: Re: Identifying no-op length coercions