Re: Removal of AcceptInvalidationMessages broke things

On Wed, Sep 19, 2012 at 01:17:17PM -0400, Tom Lane wrote:
> I looked into bug #7557, which demonstrates a case where a session fails
> to notice a just-committed change in table permissions.

> - /*
> - * Check for shared-cache-inval messages before trying to open the
> - * relation. This is needed to cover the case where the name identifies a
> - * rel that has been dropped and recreated since the start of our
> - * transaction: if we don't flush the old syscache entry then we'll latch
> - * onto that entry and suffer an error when we do RelationIdGetRelation.
> - * Note that relation_open does not need to do this, since a relation's
> - * OID never changes.
> - *
> - * We skip this if asked for NoLock, on the assumption that the caller has
> - * already ensured some appropriate lock is held.
> - */
> - if (lockmode != NoLock)
> - AcceptInvalidationMessages();
>
> and there are no other places where a transaction will do
> AcceptInvalidationMessages if it thinks it already holds lock on the
> tables it's working with.
>
> Since we have only a few hours before 9.2.1 is due to wrap, my
> inclination for a band-aid fix is to put back that code. There might be
> some more elegant answer, but we haven't got time to find it now.

Sounds fine for now. I suspect the better change would be to make
AcceptInvalidationMessages() unconditional in LockRelationOid() and friends.
There's no reason to desire recent ACLs only when opening by name.