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

Re: User-facing aspects of serializable transactions

From: Markus Wanner <markus(at)bluegap(dot)ch>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Greg Stark <stark(at)enterprisedb(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, "<pgsql-hackers(at)postgresql(dot)org>" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: User-facing aspects of serializable transactions
Date: 2009-06-01 17:27:47
Message-ID: 4A240F93.6050308@bluegap.ch (view raw or flat)
Thread:
Lists: pgsql-hackers
Hi,

Kevin Grittner wrote:
> Greg Stark <stark(at)enterprisedb(dot)com> wrote:
>> I would want any serialization failure to be
>> justifiable by simple inspection of the two transactions.
>  
> BTW, there are often three (or more) transaction involved in creating
> a serialization failure, where any two of them alone would not fail. 
> You probably knew that, but just making sure....

I'm not that eager on the "justifiable by simple inspection" requirement
above. I don't think a DBA is commonly doing these inspections at all.

I think a tool to measure abort rates per transaction (type) would serve
the DBA better. Of course there may be false positives, but high abort
rates should point out the problematic transactions pretty quickly. The
DBA shouldn't need to care about rare serialization failures or their
justifiability.

But maybe that reveals another requirement: false positives should be
rare enough for the DBA to still be able to figure out which
transactions are problematic and actually lead to conflicts.

In general, getting good performance by allowing a certain
false-positive rate seems like a good approach to me.

Regards

Markus Wanner


In response to

Responses

pgsql-hackers by date

Next:From: Markus WannerDate: 2009-06-01 17:43:28
Subject: Re: PostgreSQL Developer meeting minutes up
Previous:From: Kevin FieldDate: 2009-06-01 17:18:25
Subject: Re: plperl error format vs plpgsql error format vs pgTAP

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