Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> A callback might be using the tuple ID in a way that fails if VACUUM
> FULL moves the tuple, so I think we *have* to change it. (as you did
> already)
Yeah, I thought about that too. As things stand in 9.0 and 9.1, there's
at least a theoretical possibility of this:
1. Process A prepares a plan that includes an inline'd copy of a SQL
function. It labels the plan with the function's pg_proc TID.
2. Process B executes "VACUUM FULL pg_proc", moving the SQL function's
tuple to a different TID.
3. Process C modifies the SQL function via CREATE OR REPLACE FUNCTION,
and sends out an inval against the new TID.
4. Process A doesn't invalidate its cached plan because it thinks the
TID is for some other function; so it continues to use the obsolete
version of the function.
The only way I can see to fix that is to back-patch the last set of
changes I committed yesterday. I think that's entirely unworkable for
9.0, because of the risk of breaking third-party code that registers
syscache callbacks. Even in 9.1 it seems a bit late to be changing that
API, so I'm thinking we should leave it alone. The odds of anyone
actually getting burnt in the field by the above scenario seem lower
than the odds of causing problems with a late API change.
regards, tom lane