Re: User-facing aspects of serializable transactions

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: User-facing aspects of serializable transactions
Дата
Msg-id 4A250559.EE98.0025.1@wicourts.gov
обсуждение исходный текст
Ответ на Re: User-facing aspects of serializable transactions  (Greg Stark <stark@enterprisedb.com>)
Ответы Re: User-facing aspects of serializable transactions  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Greg Stark <stark@enterprisedb.com> wrote:
> On Tue, Jun 2, 2009 at 2:44 PM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
>> We have next to nothing which can be deleted after three months.
> That's reassuring for a courts system. :-)
> But i said "I could easily imagine". The point was that even in a
> big complex system with thousands of queries being constantly
> modified by hundreds of people, it's possible there might be some
> baseline rules.  Those rules can even be enforced using tools like
> views. So it's not true that no programmer could ever expect that
> they've written their code to ensure there's no risk of
> serialization failures.
Now I see what you're getting at.
I think we've beat this horse to death and then some.
Recap:
(1)  There is abstract, conceptual agreement that support for
serializable transactions would be A Good Thing.
(2)  There is doubt that an acceptably performant implementation is
possible in PostgreSQL.
(3)  Some, but not all, don't want to see an implementation which
produces false positive serialization faults with some causes, but
will accept them for other causes.
(4)  Nobody believes that an implementation with acceptable
performance is possible without the disputed false positives mentioned
in (3).
(5)  There is particular concern about how to handle repeated
rollbacks gracefully if we use the non-blocking technique.
(6)  There is particular concern about how to protect long-running
transactions from rollback.  (I'm not sure those concerns are confined
to the new technique.)
(7)  Some, but not all, feel that it would be beneficial to have a
correct implementation (no false negatives) even if it had significant
false positives, as it would allow iterative refinement of the locking
techniques.
(8)  One or two people feel that there would be benefit to an
implementation which reduces the false negatives, even if it doesn't
eliminate them entirely.  (Especially if this could be a step toward a
full implementation.)
Are any of those observations in dispute?
What did I miss?
Where do we go from here?
-Kevin


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

Предыдущее
От: "David E. Wheeler"
Дата:
Сообщение: Re: Managing multiple branches in git
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Managing multiple branches in git