Nicolas Barbier <nicolas.barb...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
