Jeff Davis <pgsql@j-davis.com> wrote:
> On Mon, 2011-04-04 at 07:20 -0500, Kevin Grittner wrote:
>>> a) a two-line explanation of what the feature is and why it's
>>> valuable (for the release notes, etc.)
>>> b) a wiki page with a more detailed explaination and examples
>>> oriented towards the beginning-to-intermediate PostgreSQL user.
>>>
>>> Volunteers?
>>
>> I volunteer for SSI.
>
> The way I think about SSI is that it automatically detects live
> race conditions in your SQL transactions at runtime; and protects
> you by safely rolling some of them back (which can be retried
> safely).
>
> Maybe something along those lines?
That is very accessible to an IT manager who's not a database
expert, and conceptually very clean. It doesn't directly address
what's innovative about it, though, nor does it directly address why
it's valuable -- although one could infer both through a close
reading.
To extend that such that the innovative nature and benefits are more
explicitly stated, perhaps:
SSI allows you to enforce arbitrarily complex user-defined business
rules within the database without blocking, by automatically
detecting live race conditions in your SQL transactions at runtime.
It protects you by safely rolling some of them back (which can be
retried safely).
It's more than two lines, but I'm not immediately able to see what
to cut.
By the way, I did some google searches to try to find a prior
production quality implementation, and have so far not found any. I
have discovered that SSI is a very popular TLA, including its use
for something called Server Side Includes (SSI.php) which is a
popular enough technology with databases for people to be listing
years of experience with it on their LinkedIn pages. I don't know
how much of a problem that might be. I guess at a minimum we should
add Serializable Snapshot Isolation to the Wikipedia SSI page:
http://en.wikipedia.org/wiki/SSI
Maybe we shouldn't use SSI without spelling out Serializable
Snapshot Isolation, to avoid confusion.
-Kevin
