Of course, there is a much more serious problem with the whole idea. I have worked through most of the necessary changes and I'm now down to changing heap_udate to comply with the new locking protocol.
The problem I'm now facing is that we need to know the set of updated columns pretty early -- just after calling HeapTupleSatisfiesUpdate, in fact, so that we can change a BeingUpdated result into MayBeUpdated if the set of columns is right. However, we don't know the set of updated columns until much later, when the function has already undergone a lot of other work and checked other possible error conditions. Short of resturcturing the function so that we can obtain the set of updated columns early (which I'm not fond of doing and may not even be possible), I'm thinking that we should be "optimistic" about the set of updated columns, and recheck them later. The problem with this idea, of course, is that if the test turns out to fail, we could have possibly caused a lot of work (such as TOAST changes) that now need to be discarded. In other words, the optimization is pessimizing some cases :-( I'm not seeing any other way around this ATM. -- Á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
