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 <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support