Re: Removal of AcceptInvalidationMessages broke things - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Removal of AcceptInvalidationMessages broke things
Date
Msg-id 2119.1348079105@sss.pgh.pa.us
Whole thread Raw
In response to Re: Removal of AcceptInvalidationMessages broke things  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> On Wed, Sep 19, 2012 at 01:17:17PM -0400, Tom Lane wrote:
>> 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.

I think it's enough for now because the first access to a relation in a
statement is always a name-based lookup from the parser.  Were that not
sufficient, we'd have had complaints before.

The core problem really is that GRANT/REVOKE don't take any object-level
lock on what they're changing.  A "real" fix might require sprinkling
AcceptInvalidationMessages calls into aclchk.c, but I'm unsure of the
performance costs of that.  Anyway, today is not the time to design
something better.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.
Next
From: Robert Haas
Date:
Subject: Re: Removal of AcceptInvalidationMessages broke things