From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: tick buildfarm failure |
Date: | 2014-09-23 13:56:27 |
Message-ID: | 20140923135627.GY16422@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-09-23 14:05:57 | Re: add modulo (%) operator to pgbench |
Previous Message | Tom Lane | 2014-09-23 13:54:28 | Re: add modulo (%) operator to pgbench |