From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | tick buildfarm failure |
Date: | 2014-09-23 05:45:06 |
Message-ID: | 20140923054506.GO16422@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 rules and tupledesc. Fair enough, it's
reasonably straight-forward to add an equalPolicies() and handle the
policies the same 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 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.
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..
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-09-23 05:53:55 | Re: Assertion failure in syncrep.c |
Previous Message | Pavan Deolasee | 2014-09-23 05:40:11 | Re: Assertion failure in syncrep.c |