Re: Create/alter policy and exclusive table lock

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Create/alter policy and exclusive table lock
Date: 2020-01-14 14:40:06
Message-ID: 5684.1579012806@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> writes:
> Right now changing policies (create/alter policy statements) requires
> exclusive lock of target table:

Yup.

> I wonder why do we really need exclusive lock here?

Because it affects the behavior of a SELECT.

> May be I missed something, but why we can not rely on standard MVCC
> visibility rules for pg_policy table?

We cannot have a situation where the schema details of a table might
change midway through planning/execution of a statement. The results
are unlikely to be as clean as "you get either the old behavior or the
new one", because that sequence might examine the details more than
once. Also, even if you cleanly get the old behavior, that's hardly
satisfactory. Consider

Session 1 Session 2

begin;
alter policy ... on t1 ...;
insert new data into t1;

begin planning SELECT on t1;

commit;

begin executing SELECT on t1;

With your proposal, session 2 would see the new data in t1
(because the executor takes a fresh snapshot) but it would not
be affected by the new policy. That's a security failure,
and it's one that does not happen today.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Georgios Kokolatos 2020-01-14 14:44:51 Re: Duplicate Workers entries in some EXPLAIN plans
Previous Message Daniel Verite 2020-01-14 14:37:21 Re: Making psql error out on output failures