Re: Serializable Isolation without blocking

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.
That *seems* safe on the face of it, but with HOT and such I wanted
to defer addressing that until I had the crude version working.  I'm
probably being a bit paranoid, though.  [thinks...]  I should
probably try to satisfy myself that this is indeed safe before I
start populating the new locks.  Basically, I have to confirm that
the read will see *all* new versions of a row without jumping out
early on any code path.  If that pans out, it'll save some work;
it's not something which should wait until the optimization phase if
we can help it.  Thanks.
> Btw, rw dependencies are the only thing that needs to be checked
> under SI, as "wr" and "ww" dependencies never lead to problems
Agreed; those are already covered by the underlying snapshot
isolation.
> 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?
Thanks for your posts, by the way -- you clearly have a solid grasp
of the issues.  I've been paying attention; I had just never felt
any of your posts needed any response from me before.  :-)
-Kevin