On Dec14, 2010, at 15:01 , Robert Haas wrote:
> On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflug <fgp@phlo.org> wrote:
>>> - serializable lock consistency - I am fairly certain this needs
>>> rebasing. I don't have time to deal with it right away. That sucks,
>>> because I think this is a really important change.
>> I can try to find some time to update the patch if it suffers from bit-rot. Would that help?
>
> Yes!
I've rebased the patch to the current HEAD, and re-run my FK concurrency test suite,
available from https://github.com/fgp/fk_concurrency, to verify that things still work.
I've also asserts to the callers of heap_{update,delete,lock_tuple} to verify (and document)
that update_xmax may only be InvalidTransactionId if a lockcheck_snapshot is passed to
heap_{update,delete,lock_tuple}.
Finally, I've improved the explanation in src/backend/executor/README of how row locks and
REPEATABLE READ transactions interact, and tried to state the guarantees provided by
FOR SHARE and FOR UPDATE locks more precisely.
I've published my work to https://github.com/fgp/postgres/tree/serializable_lock_consistency,
and attached an updated patch. I'd be happy to give write access to that GIT repository
to anyone who wants to help getting this committed.
best regards,
Florian Pflug
