tick buildfarm failure - Mailing list pgsql-hackers

From Stephen Frost
Subject tick buildfarm failure
Date
Msg-id 20140923054506.GO16422@tamriel.snowman.net
Whole thread Raw
Responses Re: tick buildfarm failure  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Pavan Deolasee
Date:
Subject: Re: Assertion failure in syncrep.c
Next
From: Stephen Frost
Date:
Subject: Re: Assertion failure in syncrep.c