From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP patch (v2) for updatable security barrier views |
Date: | 2014-04-11 11:39:30 |
Message-ID: | 0MdLIx-1WG5S30OWZ-00ITF2@mrelayeu.kundenserver.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(Sorry if this breaks the thread history; on mobile)
> > Am I right in thinking that the "locking gotcha" only happens if you
> > create a security_barrier view conaining a "SELECT ... FOR UPDATE"? If
> > so, that seems like rather a niche case - not that that means we
> > shouldn't warn people about it.
>
> Hmm, the 'gotcha' I was referring to was the issue discussed upthread
> around rows getting locked to be updated which didn't pass all the quals
> (they passed the security_barrier view's, but not the user-supplied
> ones), which could happen during a normal 'update' against a
> security_barrier view, right? I didn't think that would require the
> view definition to be 'FOR UPDATE';
It doesn't require the view to be defined FOR UPDATE.
I'll try to write an isolstiontester case to donstrate this on the weekend.
From | Date | Subject | |
---|---|---|---|
Next Message | lkcl . | 2014-04-11 12:20:06 | [feature] cached index to speed up specific queries on extremely large data sets |
Previous Message | Andres Freund | 2014-04-11 11:15:54 | Re: PostgreSQL in Windows console and Ctrl-C |