Re: Removal of AcceptInvalidationMessages broke things

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Removal of AcceptInvalidationMessages broke things
Дата
Msg-id 2119.1348079105@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Removal of AcceptInvalidationMessages broke things  (Noah Misch <noah@leadboat.com>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Removal of AcceptInvalidationMessages broke things