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