Re: incoherent view of serializable transactions

>>> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> 12/23/08
9:47 AM >>>
> Kevin Grittner wrote:
>>>>> Emmanuel Cecchet <manu(at)frogthinker(dot)org> 12/23/08 8:59 AM >>>
>>> Why don't users program the application to
>>> deal with a lower isolation (actually I think they do)?
>>
>> There really are good reasons. I'm not up to going through that
now,
>> but if there is genuine interest in the topic perhaps I can follow
up
>> later.
>
> Well, the reason why people rely on isolation provided by database in

> general is to make it easier to develop applications. One less thing
to
> worry about. That's why people use RDBMS, transactions, etc. to begin
with.

This is the heart of it. The argument is getting made that you don't
need serializable transactions because you can duplicate the
concurrency control with a combination of read_committed transactions
and explicit lock requests. I could also duplicate the functionality
of a DBMS with a bunch of disk files and custom, hard-coded access
logic, but I sure wouldn't want to do so.

> If you have a concrete suggestion (= patch) for the documentation,
I'm
> all ears.

Well, I figured I should try to get a consensus here before submitting
a patch. Last time I tried submitting a simple patch to remove the
line about the PostgreSQL community not knowing about any other
databases which use predicate locking, I got shot down hard.

Does the phantom receipt example from the original post seem like a
reasonable thing to include in the doc patch? Does someone have a
more comprehensive summary of where the issues are than I've been able
to generate so far?

The patch should also include information on workarounds. I'd be
inclined to frame them in terms of how to duplicate the behavior of
serializable transactions on other databases from which the reader
might be converting, which would start with using SELECT FOR SHARE for
any SELECT within a serializable transaction. That doesn't cover
everything, because, unlike Sybase, et al, it doesn't block
conflicting INSERTs. I'm not sure I have a firm conceptual grasp on
when and how that renders the SELECT FOR SHARE technique incomplete,
but I could try to think it through. If someone already has
comprehensive guidelines on that, it would save time and might improve
the quality of the docs.

-Kevin