Skip site navigation (1) Skip section navigation (2)

Re: incoherent view of serializable transactions

From: Emmanuel Cecchet <manu(at)frogthinker(dot)org>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: incoherent view of serializable transactions
Date: 2008-12-23 14:59:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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? 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. Oracle also 
provides SI like Postgres and I don't think they are doing that bad.
> 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)?

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

Emmanuel Cecchet
FTO @ Frog Thinker 
Open Source Development & Consulting
email: manu(at)frogthinker(dot)org
Skype: emmanuel_cecchet

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2008-12-23 15:14:29
Subject: Re: Proposed Patch to Improve Performance of Multi-Batch Hash Join for Skewed Data Sets
Previous:From: Joshua TolleyDate: 2008-12-23 14:51:51
Subject: Re: Proposed Patch to Improve Performance of Multi-BatchHash Join for Skewed Data Sets

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group