I said:
> Now that I think about it, the problem is almost certainly that the
> relcache+sinval mechanism isn't recognizing this update as requiring
> relcache-entry rebuild. If you update a pg_class row, it definitely
> does recognize that event as forcing relcache rebuild, and I had thought
> that updating a pg_attribute row associated with a relcache entry would
> cause one too. But maybe not.
It sure looks to me like the update of the pg_attribute row
should be sufficient to queue a relcache flush message (see
RelationInvalidateHeapTuple and subsidiary routines in
backend/utils/cache/inval.c). We could argue about whether
PrepareForTupleInvalidation needs to test for a wider variety of
relcache-invalidating updates, but nonetheless I don't see why
renameatt would be failing to trigger one. Are you sure it's
not working?
regards, tom lane