Re: Poor plan choice with partial unique indexes on jsonb column and simple RLS policy (with test script)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alastair McKinley <a(dot)mckinley(at)analyticsengines(dot)com>
Cc: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Poor plan choice with partial unique indexes on jsonb column and simple RLS policy (with test script)
Date: 2020-03-04 04:22:39
Message-ID: 22263.1583295759@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alastair McKinley <a(dot)mckinley(at)analyticsengines(dot)com> writes:
> Thank you for having a look at this. In the interim I discovered that I could trigger the issue by creating a security barrier view, whereas a regular view worked fine, so I think that also points to your conclusion about leakyness?
> I attempted to workaround the issue with a leakproof function, so far with no success.
> ...
> Is this an approach that could fundamentally work?

Forcing the expression to be considered leakproof should work.
I'm not sure that your partial index is OK for the purpose of
collecting stats, though -- does it help if you make a non-partial
index on that function expression? Otherwise, it's possible that
I guessed wrong about which part of the WHERE clause is problematic.
You could try doing EXPLAINs with different portions of the WHERE
to see how the rowcount estimate changes.

BTW, just marking something "leakproof" when it isn't really so
is possibly a security problem. You should think twice about
what threat model you're hoping RLS will protect against.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message stan 2020-03-04 11:03:22 Use of perl modules in plperl ?
Previous Message Alastair McKinley 2020-03-04 00:37:41 Re: Poor plan choice with partial unique indexes on jsonb column and simple RLS policy (with test script)