Re: Odd behavior of updatable security barrier views on foreign tables

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org >> PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Odd behavior of updatable security barrier views on foreign tables
Date: 2015-02-13 12:27:51
Message-ID: 20150213122751.GI6717@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Etsuro,

* Etsuro Fujita (fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp) wrote:
> On 2015/02/11 4:06, Stephen Frost wrote:
> >* Etsuro Fujita (fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp) wrote:
> >>On 2015/02/10 7:23, Dean Rasheed wrote:
> >>>Sorry, I didn't have time to look at this properly. My initial thought
> >>>is that expand_security_qual() needs to request a lock on rows coming
> >>>from the relation it pushes down into a subquery if that relation was
> >>>the result relation, because otherwise it won't have any locks, since
> >>>preprocess_rowmarks() only adds PlanRowMarks to non-target relations.
> >>
> >>That seems close to what I had in mind; expand_security_qual() needs
> >>to request a FOR UPDATE lock on rows coming from the relation it
> >>pushes down into a subquery only when that relation is the result
> >>relation and *foreign table*.
> >
> >I had been trying to work out an FDW-specific way to address this, but I
> >think Dean's right that this should be addressed in
> >expand_security_qual(), which means it'll apply to all cases and not
> >just these FDW calls. I don't think that's actually an issue though and
> >it'll match up to how SELECT FOR UPDATE is handled today.
>
> Sorry, my explanation was not accurate, but I also agree with Dean's
> idea. In the above, I just wanted to make it clear that such a lock
> request done by expand_security_qual() should be limited to the case
> where the relation that is a former result relation is a foreign
> table.

We aren't doing that for the other cases and so I don't think it makes
sense to do it here.. These should all be handled the same way.

> If it's OK, I'll submit a patch for that, maybe early next week.

Not really necessary, I have the code for it, just need to test, etc.

Thanks!

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-02-13 12:42:32 Re: SSL information view
Previous Message Asif Naeem 2015-02-13 12:27:37 chkpass with RANDOMIZE_ALLOCATED_MEMORY