On Fri, May 8, 2009 at 3:00 PM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > Greg Stark <st...@enterprisedb.com> wrote: >> On Thu, May 7, 2009 at 11:08 PM, Kevin Grittner >> <kevin.gritt...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers