Tom,
On Sunday, January 3, 2016, Tom Lane <
tgl@sss.pgh.pa.us> wrote:
CREATE POLICY takes AccessExclusiveLock on the table a policy is being
added to -- good -- and then releases it when done -- bad. Correct
behavior is to hold the lock till commit, because otherwise there is
no guarantee that other backends will see the updated catalog rows in
time, or indeed at all.
Agreed.
The same goes for ALTER POLICY, and possibly DROP POLICY (I've not
found the implementation of that ...)
DROP POLICY is handled through the generalized drop command and likely doesn't have a problem due to that.
If we fix this, I believe we could also remove the weasel wording that was
added to create_policy.sgml in commit 43cd468cf01007f3 about how the
system might transiently fail to enforce row security correctly.
The issue addressed there is with row locking, not table level locks. The concern is that a user could acquire a lock on a row to which their access to is then removed due to changes in rows which are used by the policy on the table- not any changes to the policy definition itself. The row that is locked might then be updated by the user who removed access to the row and the results of that update seen by the original user via RETURNING.
Peter provided a test case which illustrated the concern.
Apologies if the above isn't entirely accurate, on my phone at the moment.
Thanks!
Stephen