Re: tick buildfarm failure

* 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