* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
> On Mon, Aug 3, 2015 at 6:21 PM, Peter Geoghegan wrote:
> > On Mon, Aug 3, 2015 at 3:07 PM, Stephen Frost wrote:
> >> Thoughts? Trying to keep it straight-forward and provide a simple
> >>
On Mon, Aug 3, 2015 at 6:21 PM, Peter Geoghegan wrote:
> On Mon, Aug 3, 2015 at 3:07 PM, Stephen Frost wrote:
>> Thoughts? Trying to keep it straight-forward and provide a simple
>> solution for users to be able to address the issue, if they're worried
>>
> I'm not convinced this is the right place, but at a minimum it should be
> referenced from the RLS documentation. Further, it should be noted that
> users who have direct SQL access can control what the isolation level
> is for their transaction.
I agree that it should be referenced by the RLS
* Peter Geoghegan (p...@heroku.com) wrote:
On Mon, Jun 1, 2015 at 12:29 AM, Peter Geoghegan p...@heroku.com wrote:
If you're using another well known MVCC database system that has RLS,
I imagine when this happens the attacker similarly waits on the
conflicting (privileged) xact to finish
On Mon, Aug 3, 2015 at 3:07 PM, Stephen Frost sfr...@snowman.net wrote:
Thoughts? Trying to keep it straight-forward and provide a simple
solution for users to be able to address the issue, if they're worried
about it. Perhaps this, plus an additional paragraph which goes into
more detail
Robert,
As I mentioned up thread, I'm out until the 27th. I have posted a patch
which I will push to fix the copy.c issue, and I have already stated that
I'll address the statistics issue. Further, Joe has also been working on
issues but he was out of pocket last week attending a conference.
I'm
On Sun, Jul 19, 2015 at 8:56 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Jun 1, 2015 at 12:29 AM, Peter Geoghegan p...@heroku.com wrote:
If you're using another well known MVCC database system that has RLS,
I imagine when this happens the attacker similarly waits on the
conflicting
On Mon, Jun 1, 2015 at 12:29 AM, Peter Geoghegan p...@heroku.com wrote:
If you're using another well known MVCC database system that has RLS,
I imagine when this happens the attacker similarly waits on the
conflicting (privileged) xact to finish (in my example in the patch,
Bob's xact).
Very minor concern about RLS
This existing ExecUpdate() comment seems a little inaccurate:
/*
* Check any RLS UPDATE WITH CHECK policies
*
* If we generate a new candidate tuple after EvalPlanQual testing, we
* must loop back here and recheck any RLS policies and