BUG #17549: wrong index scan plan with RLS
От | PG Bug reporting form |
---|---|
Тема | BUG #17549: wrong index scan plan with RLS |
Дата | |
Msg-id | 17549-5114159516d34c2d@postgresql.org обсуждение исходный текст |
Ответы |
Re: BUG #17549: wrong index scan plan with RLS
|
Список | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 17549 Logged by: Zhao Rui Email address: 875941708@qq.com PostgreSQL version: 14.4 Operating system: All Description: You can reproduce in this way: create table abc (a integer, b text); insert into abc select (random()*(10^4))::integer, (random()*(10^4))::text from generate_series(1,100000); create index on abc(a, lower(b)); ALTER TABLE abc enable ROW LEVEL SECURITY; ALTER TABLE abc FORCE ROW LEVEL SECURITY; CREATE POLICY abc_id_iso_ply on abc to CURRENT_USER USING (a = (current_setting('app.a'::text))::int); # for bypass user, index scan works fine explain analyse select * from abc where a=1 and lower(b)='1234'; Index Scan using abc_a_lower_idx on abc Index Cond: ((a = 1) AND (lower(b) = '1234'::text)) # for RLS user, index scan can only use column a, and filter by lower(b) set app.a=1; explain analyse select * from abc where a=1 and lower(b)='1234'; Index Scan using abc_a_lower_idx on abc Index Cond: (a = 1) Filter: (lower(b) = '1234'::text) This only occurs when using non-leak-proof functional index. Everything works fine in following way: create index on abc(a, b); explain analyse select * from abc where a=1 and b='1234'; I think crucial function is restriction_is_securely_promotable. Maybe it is too strict to reject normal clause match. Could you please recheck RLS with functional index?
В списке pgsql-bugs по дате отправления: