On 26.05.2011 06:19, Kevin Grittner wrote:
> Dan and I went around a couple times chasing down all code, comment,
> and patch changes needed, resulting in the attached patch. We found
> and fixed the bug which originally manifested in a way which I
> confused with a need for row locks, as well as another which was
> nearby in the code. We backed out the changes which were causing
> merge problems for Robert, as those were part of the attempt at the
> row locking (versus tuple locking). We removed a function which is
> no longer needed. We adjusted the comments and an affected isolation
> test.
Could you explain in the README, why it is safe to only take the lock on
the visible row version, please? It's not quite obvious, as we've seen
from this discussion, and if I understood correctly the academic papers
don't touch that subject either.
> As might be expected from removing an unnecessary feature, the lines
> of code went down -- a net decrease of 93 lines.
That's the kind of patch I like :-).
> These changes generate merge conflicts with the work I've done on
> handling CLUSTER, DROP INDEX, etc. It seems to me that the best
> course would be to commit this, then I can rebase the other work and
> post it. Since these issues are orthogonal, it didn't seem like a
> good idea to combine them in one patch, and this one seems more
> urgent.
Agreed.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com