Re: foreign key locks, 2nd attempt

Excerpts from Alvaro Herrera's message of jue ene 26 16:03:02 -0300 2012:
> Excerpts from Alvaro Herrera's message of mar ene 24 15:47:16 -0300 2012:
>
> > Need more code changes for the following:
>
> > * export FOR KEY UPDATE lock mode in SQL
>
> While doing this, I realized that there's an open item here regarding a
> transaction that locks a tuple, and then in an aborted savepoint deletes
> it. As things stand, what happens is that the original tuple lock is
> forgotten entirely, which was one of the things I wanted to fix (and in
> fact is fixed for all other cases AFAICS). So what we need is to be
> able to store a MultiXactId that includes a member for KeyUpdate locks,
> which will represent an UPDATE that touches key columns as well as
> DELETEs. That closes the hole. However, the problem with this is that
> we have no more bits left in the flag bitmask, which is another concern
> you had raised. I chose the easy way out and added a full byte of flags
> per transaction.
>
> This means that we now have 1636 xacts per members page rather than
> 1900+, but I'm not too concerned about that. (We could cut back to 4
> flag bits per xact -- but then, having some room for future growth is
> probably a good plan anyway).
>
> So DELETEs can also create multis. I'm going to submit an updated patch
> shortly.

... and here it is. The main change here is that FOR KEY UPDATE is
supported, and multis can now represent both FOR KEY UPDATE as well as
DELETEs and UPDATEs that change the key values. I have enlarged the
status bits for each member of a multi to eight, as mentioned above.
We're currently using only three (and not completely -- we currently
have only six states to represent), so that gives us a lot of room for
growth.

(Looking at this code, I have the impression that either moving
MultiXactIdWait to heapam.c was a mistake, or defining MultiXactStatus
in multixact.h is the mistake.)

Other than that and that it's based on current master, this is pretty
much the same as version 6 of the patch.

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