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

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Stephen Frost <sfrost(at)snowman(dot)net>
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-18 09:20:44
Message-ID: 54E4596C.8060401@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On 2015/02/18 7:44, Stephen Frost wrote:
> * Etsuro Fujita (fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp) wrote:
>> On 2015/02/11 4:06, Stephen Frost wrote:
>>> 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.
>
> Attached is a patch which should address this. Would love your (or
> anyone else's) feedback on it. It appears to address the issue which
> you raised and the regression test changes are all in-line with
> inserting a LockRows into the subquery, as anticipated.

I've looked into the patch.

* The patch applies to the latest head, 'make' passes successfully, but
'make check' fails in the rowsecurity test.

* I found one place in expand_security_qual that I'm concerned about:

+ if (targetRelation)
+ applyLockingClause(subquery, 1, LCS_FORUPDATE,
+ false, false);

ISTM that it'd be better to use LockWaitBlock as the fourth argument of
applyLockingClause.

Other than that, the patch looks good to me.

Thanks for the work!

Best regards,
Etsuro Fujita

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2015-02-18 09:28:25 Re: ExplainModifyTarget doesn't work as expected
Previous Message Kyotaro HORIGUCHI 2015-02-18 08:44:40 Re: How about to have relnamespace and relrole?