Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> But at least it doesn't seem like anyone is seriously arguing that
> true serializability wouldn't be a nice feature, if hypothetically
> we had an agreed-upon implementation and a high-level developer with
> a lot of time on their hands.
If that's true, I think it represents a major shift in perspective on
this list. Does everyone *really* agree with the above?
> - Is it feasible to think about implementing this with traditionally
> blocking locks? Kevin seems to think it isn't, because it will suck
> too much.
I'm not sure it's without value to the project; I just don't know that
it would be worth using for us. It seems to be accepted in some other
DBMS products. Since some (like MS SQL Server) allow users to choose
snapshot isolation or blocking-based serializable transactions in
their MVCC implementation, it would be interesting to know how many
users have chosen the latter. Has anyone seen numbers (or even have
anecdotal evidence) on this point?
> - Is it feasible to think about implementing this with SIREAD locks?
I'd be willing to bet that if we solved the predicate locking issue,
the rest of it would be minor by comparison. But I am still trying
get comfortable with the train of thought I got onto when responding
to Greg Stark's last email on the topic.
With blocking techniques you always have at least two transactions
involved, and you can pick between at least two, when you need to roll
something back. With this new method, it is possible to discover the
dangerous structure which requires rollback when there is only one
participating transaction left active -- which might have done a lot
of work by that point. It seems like a pretty significant weakness.
Do others see that as a fatal flaw?
> - Why is this an all-or-nothing proposition? Given the undeniable
> difficulty of getting large patches committed, tying the locking-of-
> existing-rows part of the solution to the predicate-locking part of
> the solution seems like a recipe for failure.
Agreed. If we can get agreement on an approach, with a road map which
allows incremental progress, we might be able to contribute
programming for some parts, and might be able to draw in others for
reasonable chunks. Requiring all-or-nothing seems to me to be the
same as a straight thumbs-down, for all practical purposes.
Of course, there's no point starting on coding for even an incremental
change without concensus on the type of issues we've been covering in
this thread.
-Kevin