From: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Create/alter policy and exclusive table lock |
Date: | 2020-01-14 14:18:31 |
Message-ID: | aec091ee-2838-0845-2681-d41b0b2cbc75@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi hackers,
Right now changing policies (create/alter policy statements) requires
exclusive lock of target table:
/* Get id of table. Also handles permissions checks. */
table_id = RangeVarGetRelidExtended(stmt->table, AccessExclusiveLock,
0,
RangeVarCallbackForPolicy,
(void *) stmt);
Unfortunately there are use cases where policies are changed quite
frequently and this exclusive lock becomes a bottleneck.
I wonder why do we really need exclusive lock here?
Policies are stored in pg_policy table and we get RowExclusiveLock on it.
May be I missed something, but why we can not rely on standard MVCC
visibility rules for pg_policy table?
Until transaction executing CREATE/ALTER POLICY is committed, other
transactions will not see its changes in pg_policy table and perform
RLS checks according to old policies. Once transaction is committed,
everybody will switch to new policies.
I wonder if we it is possible to replace AccessExclusiveLock with
AccessSharedLock in RangeVarGetRelidExtended in CreatePolicy and
AlterPolicy?
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2020-01-14 14:34:15 | Re: Setting min/max TLS protocol in clientside libpq |
Previous Message | 曾文旌 (义从) | 2020-01-14 14:16:12 | Re: [Proposal] Global temporary tables |