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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
