Re: Serializable Isolation without blocking

Hi,

Kevin Grittner wrote:
> SIREAD locks need to be acquired according to the exact same rules
> as "normal" read locks in predicate locking schemes.

Understood. I didn't take that into account at first. Thanks for
pointing it out. (Whatever "normal" read locks are...)

> We're just
> using a lock level where the set of locks which conflict with it is
> empty. ;-)

Which kind of defeats the purpose of a lock. Anyway, that's a bike-shed
discussion, so I might as well agree to calling it a lock.

> Well, the development plan calls for it to start there. Whether a
> better way is found during optimization is anybody's guess at this
> point.

Okay, so you know my guess ;-)

> It seems both respectful and less confusing to adopt the terminology
> of those who developed SSI techniques. I could invent new terms for
> "vulnerable edges", "dangerous structures", "pivots" and such which
> are used in the relevant literature. But I won't. It would just
> serve to confuse those who have spent the time to read and
> understand the literature.

I agree.

My intention was to "translate" the literature terms to Postgres hacker
slang. At least I had trouble to understand that SIREAD is a lock that
doesn't actually block anything.

> I'm not quite sure I followed what you were getting at with the
> "(non-existent) predicate locking" phrase -- was that just an
> acknowledgment that it is exactly what is under development and, as
> such, doesn't yet exist; or were you getting at something else?

SIREAD atop predicate locking serves detecting vulnerable edges (I hope
I'm using that term correctly here) between newly inserted tuples and
reads, right? I was trying to figure if it would make sense to use
predicate locking (instead of table or row level locking) as well for
detecting vulnerable edges between updated or deleted tuples and reads.

At least you'd be free with its granularity (which cannot be said for
row or table level locking, for obvious reasons). However, it certainly
depends a lot on the implementation of predicate locking, which we don't
have, yet, so that's all speculation...

Regards

Markus Wanner