Re: tick buildfarm failure

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: tick buildfarm failure
Дата
Msg-id 12067.1411479990@sss.pgh.pa.us
обсуждение исходный текст
Ответ на tick buildfarm failure  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: tick buildfarm failure  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
>   To be a bit more clear- why is it safe to change the contents if the
>   equal() function returns 'false'?  I'm guessing the answer is
>   "locking"- whereby such a change would imply a lock was acquired on
>   the relation by another backend, which shouldn't be possible if we're
>   currently working with it, but wanted to double-check that.

Right.  If that were to fail, it would be the fault of something else
not having gotten sufficient lock for whatever it had been doing: either
lack of exclusive lock for an RLS update, or lack of an access lock to
examine the cached data.  The reason we want to make the equal() check
rather than just summarily replace the data is that code that *does*
hold AccessShare might reasonably expect the data to not move while it's
looking at it. 
>   I also wonder if we might be better off with a way to identify that
>   nothing has actually been changed due to the locks we hold and avoid
>   rebuilding the relation cache entry entirely..

I am entirely disinclined to reinvent relcache as part of the RLS patch.
You've got enough problems.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Johnston
Дата:
Сообщение: Re: RLS feature has been committed
Следующее
От: David Johnston
Дата:
Сообщение: Re: RLS feature has been committed