tick buildfarm failure
От | Stephen Frost |
---|---|
Тема | tick buildfarm failure |
Дата | |
Msg-id | 20140923054506.GO16422@tamriel.snowman.net обсуждение исходный текст |
Ответы |
Re: tick buildfarm failure
|
Список | pgsql-hackers |
All, I've been keeping an eye on tick as it failed a day-or-so ago and it looks to be related to RLS. Using a local CLFAGS="-DCLOBBER_CACHE_ALWAYS-DRANDOMIZE_ALLOCATED_MEMORY" build, I was able to see the regression tests failing in check_role_for_policy()due to a pretty clear reset of the memory used for the policies. Looking through relcache.c, which I have to admit to not being as familiar with as some, the issue becomes rather apparent(I believe)- RelationClearRelation() hasn't been set up to handle the RLS policies specially, as it does for rulesand tupledesc. Fair enough, it's reasonably straight-forward to add an equalPolicies() and handle the policies thesame way- but I'm left wondering if that's actually *safe* to do? To be a bit more clear- why is it safe to change the contents if the equal() function returns 'false'? I'm guessing theanswer is "locking"- whereby such a change would imply a lock was acquired on the relation by another backend, which shouldn'tbe possible if we're currently working with it, but wanted to double-check that. I also wonder if we might be betteroff with a way to identify that nothing has actually been changed due to the locks we hold and avoid rebuilding therelation cache entry entirely.. Thanks! Stephen
В списке pgsql-hackers по дате отправления: