Re: User-facing aspects of serializable transactions

On Thu, May 28, 2009 at 1:33 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Now let's discuss implementation. It may well be that there is no solution
> that totally satisfies all those requirements, so there's plenty of room for
> various tradeoffs to discuss. I think fully spec-compliant behavior is a
> hard requirement, or we'll find ourselves adding yet another isolation level
> in the next release to achieve it. The others are negotiable.

I'm sort of running out of enthusiasm for this thread, because it
seems like we're going around in circles again. 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.

With respect to implementation, it seems fairly clear to me that there
are two major things that we lack for true serializability: protection
against old rows disappearing out from under us (DELETE/UPDATE case),
and protection from new rows that appear under us (INSERT/UPDATE
case). Protection against the former requires locking of existing
rows; protection against the latter requires predicate locking.
[Thanks to Tom for setting me straight on this point, a few emails
upthread.] This locking could be done with either traditional
blocking locks, or with the SIREAD locks discussed in the paper Kevin
cited.

I think the things we need to get clear on are:

- 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.

- Is it feasible to think about implementing this with SIREAD locks?
That has some complex requirements which someone more familiar with
the code than me will need to read and think about. I'm not sure
whether anyone is willing to do that analysis without money changing
hands, but we're not going to make any progress here otherwise.

- 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.

...Robert