Re: Serializable Isolation without blocking

Hi,

Kevin Grittner wrote:
> Nicolas Barbier <nicolas.barbier@gmail.com> wrote:
>> AFAICS, detecting a "rw" dependency where the read executes after
>> the write is rather easy: the writer has created a row version
>> that is not visible to the reader's snapshot. Therefore, any time
>> a reader reads a non-last version of a row, there is a rw
>> dependency between it and the creators of any newer versions.

Sure.

As you have written below, we still need the SIREAD lock on the tuple
read to be able to detect rw dependencies (where the read executes
before the write).

I was trying to point out the difference between rw dependencies on
existing tuples (where the write is an update/delete) vs those on newly
created tuples (inserts) that *would* have been read. The later clearly
needs predicate locking. For the former, basing on table- as well as
row-level locking have been discussed so far.

What I'm thinking about is if it would make sense to use the very same
locking infrastructure for both, which needs to be some kind of
predicate locking. Maybe that was intended by Kevin and already clear to
others. It wasn't for me.

As we don't yet have predicate locking or tagging, let's check what SSI
needs from that building block. AFAICT we currently have the following
(long term) requirements:

A) reference rows that don't exist, yet
B) keep the lock (tag) until after the session that created it has
expired (yes, session, not only transaction).
C) fit in (shared) memory, no matter how many rows get tagged (thus
maybe use dynamical adjustment of granularity)

AFAICT using the existing locking structure will get complicated mainly
because of B), because we sometimes lack a PGPROC for the transaction
holding the lock. It's specific to SSI (not generally usable for
predicate locking).

A) and C) might be usable for a general purpose predicate locking
mechanism as well, but those requirements make it hard to map the object
to be locked to a LOCKTAG.

Unlike a general purpose predicate locking implementation, we don't need
to block on SIREAD locks, so we don't need waiting queues nor deadlock
detection for SSI.

> Basically, I have to confirm that
> the read will see *all* new versions of a row without jumping out
> early on any code path.

Well, a heap scan immediately returns the currently visible version of a
row to the caller, for example. That one may or may not continue the
scan. So I fear yes, current code paths jump out early very often (as
that's an optimization for the LIMIT case as well).

>> I assume here that PG's non-SI-compatible behavior of not always
>> rollbacking any transaction that writes to a non-last version will
>> be disabled in serializable mode.
>  
> Can that currently happen in PostgreSQL's snapshot isolation?!?  I
> thought that was a READ COMMITTED issue.  If I've missed something
> there, I need to understand what.  Anybody?

A write to a non-last (or non-head) version would lead to having
multiple "last" (or rather multiple head) versions, which is not
something that's ever supposed to happen in Postgres, IIRC.

Regards

Markus Wanner