* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> 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.
Ok, great, thanks for the confirmation. Yes- the RLS code wasn't
anticipating a change happening underneath it such as this (as other
places didn't appear worried about same, I didn't expect to see it be an
issue). No problem, I'll definitely address 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.
Apologies- I hadn't intend to even suggest that but rather to speculate
about this possibility for future improvements.
Thanks again!
Stephen