On 13 April 2014 05:23, Stephen Frost wrote:
> Alright, I've committed this with an updated note regarding the locking,
> and a few additional regression tests
That's awesome. Thank you very much.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
Greg,
* Gregory Smith (gregsmithpg...@gmail.com) wrote:
> Now that Tom has given some guidance on the row locking weirdness,
> maybe it's time for me to start updating those into make check form.
If you have time, that'd certainly be helpful.
> The documentation has been in a similar holding pat
All,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Yeah, the point of the "gotcha" is that a FOR UPDATE specified *outside* a
> security-barrier view would act as though it had appeared *inside* the
> view, since it effectively gets pushed down even though outer quals don't.
Alright, I've committed th
Stephen Frost writes:
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> Am I right in thinking that the "locking gotcha" only happens if you
>> create a security_barrier view conaining a "SELECT ... FOR UPDATE"? If
>> so, that seems like rather a niche case - not that that means we
>> shouldn'
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> > Hmm, the 'gotcha' I was referring to was the issue discussed upthread
> > around rows getting locked to be updated which didn't pass all the quals
> > (they passed the security_barrier view's, but not the user-supplied
> > ones), which could happ
(Sorry if this breaks the thread history; on mobile)
> > Am I right in thinking that the "locking gotcha" only happens if you
> > create a security_barrier view conaining a "SELECT ... FOR UPDATE"? If
> > so, that seems like rather a niche case - not that that means we
> > shouldn't warn people
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 11 April 2014 04:04, Stephen Frost wrote:
> > which changes it to "if a relation was changed to a subquery, it had
> > better be because it's got securityQuals that we're dealing with". My
> > general thinking here is that we'd be bette
On 11 April 2014 04:04, Stephen Frost wrote:
> Dean, Craig, all,
>
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> This is reflected in the change to the regression test output where,
>> in one of the tests, the ctids for the table to update are no longer
>> coming from the same table. I thi
Dean, Craig, all,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> This is reflected in the change to the regression test output where,
> in one of the tests, the ctids for the table to update are no longer
> coming from the same table. I think a better approach is to push down
> the rowmark int
On 4/9/14 9:56 PM, Stephen Frost wrote:
As for docs and testing, those are things we would certainly be better
off with and may mean that this isn't able to make it into 9.4, which is
fair, but I wouldn't toss it out solely due to that.
We have a git repo with multiple worked out code examples,
Stephen Frost writes:
> Interesting. I'm trying to reason out why we don't have it already in
> similar situations; we can't *always* flatten a subquery...
I think we do, just nobody's particularly noticed (which further reduces
the urgency of finding a solution, I suppose).
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> That sounds a bit confused.
It was- I clearly hadn't followed the thread entirely.
> The quals aren't getting to see rows they
> shouldn't be allowed to see. The issue rather is whether rows that the
> user quals would exclude might get locked anyway be
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> So if you wanted user-supplied quals to limit which rows get locked
>> physically, they would need to be applied before the lower LockRows node.
> Right.
>> To my mind, it's not immediately apparent that that is a reasonable
>> ex
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Dean Rasheed writes:
> > On 10 March 2014 03:36, Craig Ringer wrote:
> >> I've found an issue with updatable security barrier views. Locking is
> >> being pushed down into the subquery. Locking is thus applied before
> >> user-supplied quals are, so we pot
Dean Rasheed writes:
> On 10 March 2014 03:36, Craig Ringer wrote:
>> I've found an issue with updatable security barrier views. Locking is
>> being pushed down into the subquery. Locking is thus applied before
>> user-supplied quals are, so we potentially lock too many rows.
> That has nothing
On 10 March 2014 03:36, Craig Ringer wrote:
> I've found an issue with updatable security barrier views. Locking is
> being pushed down into the subquery. Locking is thus applied before
> user-supplied quals are, so we potentially lock too many rows.
>
> I'm looking into the code now, but in the m
I've found an issue with updatable security barrier views. Locking is
being pushed down into the subquery. Locking is thus applied before
user-supplied quals are, so we potentially lock too many rows.
I'm looking into the code now, but in the mean time, here's a demo of
the problem:
regress=> C
On 01/31/2014 05:09 PM, Dean Rasheed wrote:
> I don't like this fix --- you appear to be adding another RTE to the
> rangetable (one not in the FROM list) and applying the rowmarks to it,
> which seems wrong because you're not locking the right set of rows.
> This is reflected in the change to the
On 30 January 2014 11:55, Dean Rasheed wrote:
> Hmm, looks like this is a pre-existing bug.
>
> The first thing I tried was to reproduce it using SQL, so I used a
> RULE to turn a DELETE into a SELECT FOR UPDATE. This is pretty dumb,
> but it shows the problem:
>
> CREATE TABLE foo (a int);
> CRE
On 30 January 2014 05:36, Craig Ringer wrote:
> On 01/29/2014 08:29 PM, Dean Rasheed wrote:
>> On 29 January 2014 11:34, Craig Ringer wrote:
>>> On 01/23/2014 06:06 PM, Dean Rasheed wrote:
On 21 January 2014 09:18, Dean Rasheed wrote:
> Yes, please review the patch from 09-Jan
> (ht
On 29 January 2014 12:20, Dean Rasheed wrote:
>> @Dean: If we moved that to rewriter, would expand_security_quals() and
>> preprocess_rowmarks() also move?
>>
>
> Actually I tend to think that expand_security_quals() should remain
> where it is, regardless of where inheritance expansion happens.
On 29 January 2014 06:43, Tom Lane wrote:
> Kouhei Kaigai writes:
>> Let me ask an elemental question. What is the reason why inheritance
>> expansion logic should be located on the planner stage, not on the tail
>> of rewriter?
>
> I think it's mostly historical. You would however have to think
On 29 January 2014 11:34, Craig Ringer wrote:
> On 01/23/2014 06:06 PM, Dean Rasheed wrote:
>> On 21 January 2014 09:18, Dean Rasheed wrote:
>>> Yes, please review the patch from 09-Jan
>>> (http://www.postgresql.org/message-id/CAEZATCUiKxOg=voovja2s6g-sixzzxg18totggp8zobq6qn...@mail.gmail.com).
On 29 January 2014 11:27, Simon Riggs wrote:
> On 29 January 2014 06:43, Tom Lane wrote:
>
>> Actually though, isn't this issue mostly about inheritance of a query
>> *target* table?
>
> Exactly. IMHO updateable views on inheritance sets will have multiple
> other performance problems, so trying
On 01/23/2014 06:06 PM, Dean Rasheed wrote:
> On 21 January 2014 09:18, Dean Rasheed wrote:
>> Yes, please review the patch from 09-Jan
>> (http://www.postgresql.org/message-id/CAEZATCUiKxOg=voovja2s6g-sixzzxg18totggp8zobq6qn...@mail.gmail.com).
>>
>
> After further testing I found a bug --- it i
On 29 January 2014 06:43, Tom Lane wrote:
> Actually though, isn't this issue mostly about inheritance of a query
> *target* table?
Exactly. IMHO updateable views on inheritance sets will have multiple
other performance problems, so trying to support them here will not
make their usage seamless.
On 28 January 2014 21:28, Robert Haas wrote:
> On Tue, Jan 28, 2014 at 5:02 AM, Simon Riggs wrote:
>> I agree that this is being seen the wrong way around. The planner
>> contains things it should not do, and as a result we are now
>> discussing enhancing the code that is in the wrong place, whic
On 01/29/2014 03:34 PM, Kouhei Kaigai wrote:
>> Kouhei Kaigai writes:
>>> Let me ask an elemental question. What is the reason why inheritance
>>> expansion logic should be located on the planner stage, not on the
>>> tail of rewriter?
>>
>> I think it's mostly historical. You would however have
;re doing now.
How about your opinion?
Thanks,
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Wednesday, January 29, 2014 3:43 PM
> To: Kaigai, Kouhei(海外, 浩平)
> Cc: Craig Ringer; S
Kouhei Kaigai writes:
> Let me ask an elemental question. What is the reason why inheritance
> expansion logic should be located on the planner stage, not on the tail
> of rewriter?
I think it's mostly historical. You would however have to think of a
way to preserve the inheritance relationships
On Tue, Jan 28, 2014 at 5:02 AM, Simon Riggs wrote:
> I agree that this is being seen the wrong way around. The planner
> contains things it should not do, and as a result we are now
> discussing enhancing the code that is in the wrong place, which of
> course brings objections.
>
> I think we wou
On 28 January 2014 04:10, Kouhei Kaigai wrote:
>> > AFAICS the only area of objection is the handling of inherited
>> > relations, which occurs within the planner in the current patch. I can
>> > see that would be a cause for concern since the planner is pluggable
>> > and it would then be possibl
January 28, 2014 12:35 PM
> To: Simon Riggs; Dean Rasheed
> Cc: Kaigai, Kouhei(海外, 浩平); Tom Lane; PostgreSQL Hackers; Kohei KaiGai;
> Robert Haas
> Subject: Re: [HACKERS] WIP patch (v2) for updatable security barrier views
>
> On 01/28/2014 12:09 AM, Simon Riggs wrote:
> > O
On 01/28/2014 12:09 AM, Simon Riggs wrote:
> On 27 January 2014 15:04, Dean Rasheed wrote:
>
>> So for example, when planning the query to update an inheritance
>> child, the rtable will contain an RTE for the parent, but it will not
>> be referenced in the parse tree, and so it will not be expan
On 27 January 2014 16:11, Tom Lane wrote:
> Simon Riggs writes:
>> Am I right in thinking that we have this fully working now?
>
> I will look at this at some point during the CF, but have not yet,
> and probably won't as long as it's not marked "ready for committer".
I've marked it Ready for Co
On 27 January 2014 15:04, Dean Rasheed wrote:
> So for example, when planning the query to update an inheritance
> child, the rtable will contain an RTE for the parent, but it will not
> be referenced in the parse tree, and so it will not be expanded while
> planning the child update.
Am I right
Simon Riggs writes:
> Am I right in thinking that we have this fully working now?
I will look at this at some point during the CF, but have not yet,
and probably won't as long as it's not marked "ready for committer".
regards, tom lane
--
Sent via pgsql-hackers mailing
On 27 January 2014 07:54, Kouhei Kaigai wrote:
> Hello,
>
> I checked the latest updatable security barrier view patch.
> Even though I couldn't find a major design problem in this revision,
> here are two minor comments below.
>
> I think, it needs to be reviewed by committer to stick direction
>
Ringer; Tom Lane; PostgreSQL Hackers; Kohei KaiGai; Robert Haas;
> Simon Riggs
> Subject: Re: [HACKERS] WIP patch (v2) for updatable security barrier views
>
> On 21 January 2014 09:18, Dean Rasheed wrote:
> > Yes, please review the patch from 09-Jan
> >
> (
On 23 January 2014 06:13, KaiGai Kohei wrote:
> A minor comment is below:
>
> ! /*
> !* Make sure that the query is marked correctly if the added
> qual
> !* has sublinks.
> !*/
> ! if (!parsetree->hasSubLinks)
> ! parsetree->ha
(2014/01/21 18:18), Dean Rasheed wrote:
On 21 January 2014 01:09, KaiGai Kohei wrote:
(2014/01/13 22:53), Craig Ringer wrote:
On 01/09/2014 11:19 PM, Tom Lane wrote:
Dean Rasheed writes:
My first thought was that it should just preprocess any security
barrier quals in subquery_planner()
On 21 January 2014 01:09, KaiGai Kohei wrote:
> (2014/01/13 22:53), Craig Ringer wrote:
>>
>> On 01/09/2014 11:19 PM, Tom Lane wrote:
>>>
>>> Dean Rasheed writes:
My first thought was that it should just preprocess any security
barrier quals in subquery_planner() in the same way as
On 01/21/2014 09:09 AM, KaiGai Kohei wrote:
> (2014/01/13 22:53), Craig Ringer wrote:
>> On 01/09/2014 11:19 PM, Tom Lane wrote:
>>> Dean Rasheed writes:
My first thought was that it should just preprocess any security
barrier quals in subquery_planner() in the same way as other quals ar
(2014/01/13 22:53), Craig Ringer wrote:
On 01/09/2014 11:19 PM, Tom Lane wrote:
Dean Rasheed writes:
My first thought was that it should just preprocess any security
barrier quals in subquery_planner() in the same way as other quals are
preprocessed. But thinking about it further, those quals
On 01/09/2014 11:19 PM, Tom Lane wrote:
> Dean Rasheed writes:
>> My first thought was that it should just preprocess any security
>> barrier quals in subquery_planner() in the same way as other quals are
>> preprocessed. But thinking about it further, those quals are destined
>> to become the qua
On 12 January 2014 10:12, Craig Ringer wrote:
> On 01/09/2014 06:48 PM, Dean Rasheed wrote:
>> On 8 January 2014 10:19, Dean Rasheed wrote:
>>> The assertion failure with inheritance and sublinks is a separate
>>> issue --- adjust_appendrel_attrs() is not expecting to find any
>>> unplanned subli
On 01/09/2014 11:19 PM, Tom Lane wrote:
> Dean Rasheed writes:
>> My first thought was that it should just preprocess any security
>> barrier quals in subquery_planner() in the same way as other quals are
>> preprocessed. But thinking about it further, those quals are destined
>> to become the qua
On 01/09/2014 06:48 PM, Dean Rasheed wrote:
> On 8 January 2014 10:19, Dean Rasheed wrote:
>> The assertion failure with inheritance and sublinks is a separate
>> issue --- adjust_appendrel_attrs() is not expecting to find any
>> unplanned sublinks in the query tree when it is invoked, since they
On 9 January 2014 15:19, Tom Lane wrote:
> Dean Rasheed writes:
>> My first thought was that it should just preprocess any security
>> barrier quals in subquery_planner() in the same way as other quals are
>> preprocessed. But thinking about it further, those quals are destined
>> to become the q
Dean Rasheed writes:
> My first thought was that it should just preprocess any security
> barrier quals in subquery_planner() in the same way as other quals are
> preprocessed. But thinking about it further, those quals are destined
> to become the quals of subqueries in the range table, so we don
Dean,
Short version
-
Looks amazing overall. Very clever to zip up the s.b. quals, let the
rest of the rewriter and planer do their work normally, then unpack them
into subqueries inserted in the planner once inheritance appendrels are
expanded, etc.
My main concern is that the secur
On 01/08/2014 02:00 PM, Craig Ringer wrote:
> I'm not sure I understand how this would work in the face of multiple
> levels of nesting s.b. views. Are you thinking of doing recursive expansion?
Never mind, that part is clearly covered in the patch.
--
Craig Ringer http://ww
> I've been thinking about this some more and I don't think you can
> avoid the need to remap vars and attrs.
I agree. I was hoping to let expand_targetlist / preprocess_targetlist
do the job, but I'm no longer convinced that'll do the job without
mangling them in the process.
> AIUI, your modifi
Hi all
Here's an updated version of the updatable security barrier views patch
that's proposed as the next stage of progressing row-security toward
useful and maintainable inclusion in core.
If updatable security barrier views are available then the row-security
code won't have to play around wit
54 matches
Mail list logo
