Re: serializable lock consistency - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: serializable lock consistency
Date
Msg-id 4D0F405B0200002500038834@gw.wicourts.gov
Whole thread Raw
In response to Re: serializable lock consistency  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: serializable lock consistency  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> wrote:
> Kevin Grittner's work is a whole different approach to this
> problem, and while that's obviously not fully debugged and
> committed yet either, it's often easier to design a new tool to
> solve a particular problem than to make an existing tool that was
> really meant for something else do some new thing in addition.
I see Florian's patch meeting a real need though, even though it is
an orthogonal solution to the same problem.  For those converting to
PostgreSQL from Oracle, there are shops with a lot of code
which counts on the behavior which Florian is trying to implement. 
Without Florian's patch, if they do a minimal-effort conversion to
PostgreSQL (without removing SELECT FOR SHARE/UPDATE clauses or
explicit locks) and count on SSI behavior, they will be paying for
the cost of integrity enforcement *twice*.  It also may be useful
for those who can't easily structure their code to automatically
retry transactions which experience a serialization failure.
For those shops doing "green field" development or converting from
products with true serializability (DB2, Sybase ASE, InnoDB, etc.)
it will probably be easier for them to just use SSI; and I have
reason to believe that SSI will generally perform better, so
Florian's patch doesn't obviate the need for SSI.
-Kevin


pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Extensions and custom_variable_classes
Next
From: Alvaro Herrera
Date:
Subject: Re: Extensions and custom_variable_classes