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. -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers