Re: Odd behavior of updatable security barrier views on foreign tables - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Odd behavior of updatable security barrier views on foreign tables
Date
Msg-id 20150218124439.GM6717@tamriel.snowman.net
Whole thread Raw
In response to Re: Odd behavior of updatable security barrier views on foreign tables  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: Odd behavior of updatable security barrier views on foreign tables
List pgsql-hackers
Etsuro,

* Etsuro Fujita (fujita.etsuro@lab.ntt.co.jp) wrote:
> On 2015/02/18 7:44, Stephen Frost wrote:
> >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.

Apologies for not being clear- the patch was against 9.4, where it
passes all the regression tests (at least for me- if you see
differently, please let me know!).

> * 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.

LockWaitBlock isn't in 9.4. :)  Otherwise, I'd agree, and it's what I
plan to do for master.

> Other than that, the patch looks good to me.

Great, thanks!
Stephen

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Parallel Seq Scan
Next
From: Neil Tiffin
Date:
Subject: Re: pgaudit - an auditing extension for PostgreSQL