Re: foreign key locks, 2nd attempt

Here's an updated version of this patch. It fixes many of Noah's review
points from the previous version, and it also contains some fixes for
other problems. The most glaring one was the fact that when we locked
an old version of a tuple, the locking code did not walk the update
chain to make the newer versions locked too. This is necessary for
correctness; moreover, locking a tuple whose future version is being
deleted by a concurrent transaction needs to cause the locking
transaction to block until the deleting transaction finishes. The
current code correctly sleeps on the deleter (or, if the deleter has
already committed, causes the tuple lock acquisition to fail.)

One other interesting change is that I flipped the
HEAP_UPDATE_KEY_INTACT bit meaning, so that it's now
HEAP_UPDATE_KEY_REVOKED; it's now set not only when an UPDATE changes a
key column, but also when a tuple is deleted. Only now that I write
this message I realize that I should have changed the name too, because
it's no longer just about UPDATE.

There are a number of smaller items still remaining, and I will be
working on those in the next few days. Most notably,

- I have not updated the docs yet.

- I haven't done anything about exposing FOR KEY UPDATE to the SQL
level. There clearly isn't consensus about exposing this; in fact there
isn't consensus on exposing FOR KEY SHARE, but I haven't changed that
from the previous patch, either.

- pg_rowlocks hasn't been updated; in this patch it's in the same shape
as it was previously. I agree with the idea that this module should
display user-level lock information instead of just decoding infomask
bits.

- I'm not sure that the multixact truncation code is sane on
checkpoints. It might be that I need to tweak more the pg_control info
we keep about truncation. The whole truncation thing needs more
testing, too.

- pg_upgrade bits are missing.

- Go over Noah's two reviews again and see if I missed anything; also
make sure I haven't missed anything from other reviewers.

At the core, ISTM this patch is in much closer form to final. The
number of things that are still open is much shorter. I'm pretty sure
this can be taken to committable state during the 2012-01 commitfest.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support