On Fri, May 8, 2009 at 3:00 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Greg Stark <stark@enterprisedb.com> wrote:
>> On Thu, May 7, 2009 at 11:08 PM, Kevin Grittner
>> <Kevin.Grittner@wicourts.gov> wrote:
>>> I would assume that SELECT shown above would either resolve to a
>>> table scan, in which case you would have to have an SIREAD lock at
>>> the table level
>>
>> That sounds like we're back to the MSSQL/Sybase way of doing things
>
> Other than not blocking, I suppose.
>
>> where you have to understand the query plan to understand why you're
>> getting spurious serialization failures.
>
> You have to know a lot more than that to solve serialization problems
> in PostgreSQL with current techniques.
Well you have to understand how Postgres locks work, but that's an
invariant. You don't have to know how Postgres is going to plan your
specific queries -- which you can't ever be sure of since it could
change as the data changes.
>> I don't think that's terribly appealing. Consider, for example, that
>> we might not *want* to do an index scan just because there's an
>> index.
>
> Someone more familiar than I with S2PL would be better able to
> respond, but I *think* you just need to track this on whatever path
> is actually chosen, not on all possible paths.
Well I don't understand what storing locks in an index can accomplish
if other queries might use other indexes or sequential scans to access
the records and never see those locks.
Or does this method only require that writers discover the locks and
therefore only writers can ever fail due to serialization failures
they cause?
I still haven't actually read the paper so I should probably bow out
from the conversation until I do. I was apparently already under one
misapprehension as Laurenz just claimed the paper does not show how to
prevent "phantoms" (phantom reads I assume?). Perhaps it's not as
ambitious as achieving true serializability after all?
--
greg