Re: incoherent view of serializable transactions

>>> Emmanuel Cecchet <manu(at)frogthinker(dot)org> 12/23/08 8:59 AM >>>
> Kevin Grittner wrote:
>> This isn't some hypothetical "maybe some day some product might
>> implement this, but it'll never catch on" sort of thing --
Microsoft
>> and Sybase SQL Server had this from version 1. I used it from 1990
>> until the conversion to PostgreSQL over the last couple years.
>
> Have you ever used serializable transactions with Sybase?

Every day for over 15 years.

> The locking is
> actually based on memory-pages and you end-up with deadlocks if you
> don't pad your data structures to prevent false sharing.

We only padded one table, which we were using to assign sequence
numbers. Eventually they did come out with support for row level
locking, which could be chosen on a table by table basis, which
eliminated the need for the padding columns. We didn't go to
row-level locking for all tables because the performance hit was
significant -- worse than the blocking. Blocking was occasionally an
issue. Deadlocks were initially a problem, but they can be handled
automatically with resubmit, which we eventually covered gracefully,
and they weren't an issue for us after that.

> Oracle also
> provides SI like Postgres and I don't think they are doing that bad.

I don't quire understand. Could you clarify?

>> I'm going on second-hand information here, but I'm told that IBM
DB2
>> has used similar techniques to provide true serializable
transactions
>> for even longer.
>>
>> I'm somewhat mystified at the reaction this topic gets here. :-
> I am somewhat mystified by the interest some people still have in
> serializable transactions. 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.

> But I am probably missing the point which was to fix the doc?

Thank you!

-Kevin