Re: [v9.2] Fix Leaky View Problem

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Kohei(dot)Kaigai(at)emea(dot)nec(dot)com, thom(at)linux(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [v9.2] Fix Leaky View Problem
Date: 2011-12-03 08:19:25
Message-ID: CADyhKSUGwN68i7tewO0P1Jfrz8gZ=PH_+TWS0H+5vHaoc0QkWA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sorry, patches were not attached. Again.

I rebased my patch set. New functions in pg_proc.h prevented to apply
previous revision cleanly. Here is no functional changes.

Thanks,

2011/12/3 Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>:
> I rebased my patch set. New functions in pg_proc.h prevented to apply
> previous revision cleanly. Here is no functional changes.
>
> 2011/11/3 Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>:
>> 2011/11/2 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> writes:
>>>> The reason why I redefined the relid of RangeTblEntry is to avoid
>>>> the problem when security_barrier attribute get changed by concurrent
>>>> transactions between rewriter and planenr stage.
>>>
>>> This is complete nonsense.  If the information is being injected into
>>> the querytree by the rewriter, it's sufficient to assume that it's up to
>>> date.  Were it not so, we'd have problems with CREATE OR REPLACE RULE,
>>> too.
>>>
>> I revised the patches to revert redefinition in relid of RangeTblEntry, and
>> add a flag of "security_barrier".
>> I seems to work fine, even if view's property was changed between
>> rewriter and planner stage.
>>
>> postgres=# CREATE VIEW v1 WITH (security_barrier) AS SELECT * FROM t1
>> WHERE a % 2 = 0;
>> CREATE VIEW
>> postgres=# PREPARE p1 AS SELECT * FROM v1 WHERE f_leak(b);
>> PREPARE
>> postgres=# EXECUTE p1;
>> NOTICE:  f_leak => bbb
>> NOTICE:  f_leak => ddd
>>  a |  b
>> ---+-----
>>  2 | bbb
>>  4 | ddd
>> (2 rows)
>>
>> postgres=# ALTER VIEW v1 SET (security_barrier=false);
>> ALTER VIEW
>> postgres=# EXECUTE p1;
>> NOTICE:  f_leak => aaa
>> NOTICE:  f_leak => bbb
>> NOTICE:  f_leak => ccc
>> NOTICE:  f_leak => ddd
>> NOTICE:  f_leak => eee
>>  a |  b
>> ---+-----
>>  2 | bbb
>>  4 | ddd
>> (2 rows)
>>
>> postgres=# ALTER VIEW v1 SET (security_barrier=true);
>> ALTER VIEW
>> postgres=# EXECUTE p1;
>> NOTICE:  f_leak => bbb
>> NOTICE:  f_leak => ddd
>>  a |  b
>> ---+-----
>>  2 | bbb
>>  4 | ddd
>> (2 rows)
>>
>> Thanks,
>> --
>> KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
>
>
>
> --
> KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

Attachment Content-Type Size
pgsql-v9.2-fix-leaky-view.part-1.v7.patch application/octet-stream 44.5 KB
pgsql-v9.2-fix-leaky-view.part-2.v7.patch.gz application/x-gzip 74.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message NISHIYAMA Tomoaki 2011-12-03 08:24:44 Re: [PATCH] PostgreSQL fails to build with 32bit MinGW-w64
Previous Message Kohei KaiGai 2011-12-03 08:18:00 Re: [v9.2] Fix Leaky View Problem