Re: Serializable Isolation without blocking

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <robertmhaas(at)gmail(dot)com>
Cc: <nicolas(dot)barbier(at)gmail(dot)com>,<gsstark(at)mit(dot)edu>, <pgsql-hackers(at)postgresql(dot)org>, <laurenz(dot)albe(at)wien(dot)gv(dot)at>
Subject: Re: Serializable Isolation without blocking
Date: 2009-12-31 21:44:02
Message-ID: 4B3CC6C2020000250002DBD7@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:

> OK. I think it will become more clear whether the existing lock
> data structures are adequate as you move into detailed design.

I've gotten far enough in reviewing it to be pretty convinced that
they'll cover all the granularities I'm likely to want unless I get
to the point of wanting to try to lock individual columns within
individual rows. It probably won't come to that, so I figure I'll
cross that bridge if and when I come to it.

> As an overall design comment, I sometimes find that it helps to
> create a working implementation of something, even if I know that
> the performance will suck or that the result will not be
> committable for other reasons. There is often value to that just
> in terms of getting your head around the parts of the code that
> need to be modified.

That's exactly where I've been trying to go at this point.

> I wonder if you couldn't start with something ridiculously poor,
> like maybe an S2PL implementation with only table-level granularity
> - just make any operation that reads or writes a table grab an
> ACCESS EXCLUSIVE lock until transaction commit.

There's an idea I hadn't thought of -- doing S2PL but with ACCESS
EXCLUSIVE locks for the read locks to test the predicate locking. It
would let me play around with testing that phase before I moved to
the next with minimal wasted effort.

> Convince yourself that it is CORRECT - forget performance. Then
> either change the locks to SIREAD, or try to weaken the locks to
> row-level in certain cases. Then do the other one. It'll take you
> a while before you have something that can seriously be considered
> for commit, but that's not the point. The point is you'll have
> working code that you can fool with.

We're very much on the same page. My goal was to get predicate
locking that didn't miss anything, even though it was ridiculously
coarse, then implement the simplest possible SSI on top of it, without
worrying about optimizations, then incrementally move toward
production quality. I clearly didn't communicate that as well as I'd
hoped. :-( Anyway, I'll think about the S2PL with ACCESS EXCLUSIVE
locks for reads; if I can't punch any holes in that as a valid
environment to test the predicate locking logic, I'll do that first,
then switch them to SIREAD locks and work on the SSI logic.

> And use git so you can keep merging up to CVS HEAD easily.

I know. It's on my list to do soon.

Thanks again,

-Kevin

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2009-12-31 21:48:52 Patch v2: Remove all declarations from pg_attribute.h, consolidate BKI scripts
Previous Message Simon Riggs 2009-12-31 21:29:48 Re: Thoughts on statistics for continuously advancing columns