On Fri, Sep 12, 2014 at 12:57 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Fri, Sep 12, 2014 at 2:15 AM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
>> Amit: did you notice that paragraph in the README? If not, and now that you
>> have read it, does that paragraph make things clear? If that's not enough,
>> what do you think is missing?
>
> Amit raised the fact that L&Y say that no read locks are required, so
> clearly he read that paragraph. We don't try and justify that right
> now, and trying to explain the whole point of L&Y without first
> explaining this satisfactorily seems odd. The current text reads:
>
> """
> Lehman and Yao don't require read locks, but assume that in-memory
> copies of tree pages are unshared.
> """
>
> If they assume that they're unshared, uh, then why bother with all
> that locking stuff? Or does this mean that page reads and writes are
> (dubiously) assumed atomic without locks? If you take a step back, you
> can see how confusing that is. L&Y don't get around to explaining
> this, but it's pretty clear that this is what's going on. If L&Y did a
> better job of explaining their algorithm, they'd just say that the
> "latch coupling" (coupling, or "crabbing", of what we'd call buffer
> locks) previously required is no longer required, but single shared
> locks are required. As I pointed out, it looks like someone figured
> out a way to make that true much, much later [1]. I think page-level
> MVCC designs might have also been used, but basically our
> interpretation of L&Y is the standard one. We cannot really be
> considered to have deviated from L&Y, since AFAICT everyone else went
> with the same interpretation.
Gosh, I think you're making this way more complicated than it needs to
be. My interpretation of the above statement was that they knew
individual page reads and writes would need to be made atomic -
probably using some form of simple locking - but omitted that from
their pseudocode for clarity. Such elisions are common in computer
science literature and don't typically detract from understanding. It
is assumed that the implementor knows enough to avoid the trivial
pitfalls of whatever is being discussed and therefore focuses on the
higher-level algorithmic issues.
If this is what we're arguing about, it's completely not worth the
time we've spent on it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company