Re: Pending 9.4 patches
От | Craig Ringer |
---|---|
Тема | Re: Pending 9.4 patches |
Дата | |
Msg-id | 5344A16D.7060003@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Pending 9.4 patches (Stephen Frost <sfrost@snowman.net>) |
Список | pgsql-hackers |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/09/2014 01:54 AM, Stephen Frost wrote: > * Robert Haas (robertmhaas@gmail.com) wrote: >> On Tue, Apr 8, 2014 at 11:59 AM, Gregory Smith >> <gregsmithpgsql@gmail.com> wrote: >>> I have no other projects ahead of this for the remainder of >>> this month. I just can't figure out what to do next until >>> there's a committer (or committers, if someone else is going to >>> take on the locking bug) identified. I looked at the locking >>> problem enough to know that one is over my head. >> >> What post or thread should I read for details about this locking >> bug? > > I think it was discussed a couple times, but it's here: > > http://www.postgresql.org/message-id/531D3355.6010403@2ndquadrant.com Yep. > The follow-ups are important though - showing that it's actually a pre-existing bug, and while it might also occur in updatable security barrier views, there's already a locking problem in the existing security barrier views that needs to be fixed. The short version is: When you have a RowMark (SELECT ... FOR UPDATE/SHARE, UPDATE, or DELETE) on the results of a query, security barrier views are incorrectly pushing this row mark down into the security_barrier subquery they generate. That means that if you: SELECT * FROM some_view FOR UPDATE WHERE id % 2 = 0; you should be locking only *even numbered* rows that match the predicate of "some_view", but in fact, what'll get run looks like the pseudo-SQL: SELECT * FROM ( SELECT * FROM underlying_table WHERE view_predicate FOR UPDATE ) some_view FOR UPDATE; i.e. we're locking *all rows that match the view predicate*, failing to apply the *user* predicate before locking. - -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTRKFtAAoJELBXNkqjr+S2pa8IAI1UJPstG1EIcoT5szB7BXWT FBnRpe5zECM1faZuHAjx9dRYXGjv/u5E+wq2jwocXLqRPIf4Cu90KDmwx3O2gCPO psv8lpfkmjX7MGtuz4Y1A8OkcB+Q3m+4neV+NpFnPA5A3Dx7WLjiFCdHTurlvtD1 BZxK0YkUWw3S40v67MZtcOIrCRwVPQP9NS+PEt3WfTydRryXecOKnJxdolH6H4A8 1inCLvIfphkCChFMiLV6r+mzzi4JxRiPEwWg3uccLRhCwcTf1BQJcXbiKdbcTYBW XT5CSyVm76gpd3WkFfxahlXkaSLOrzGney0LGHUI4ItunlxQzPgQhx2ghc97P9w= =H425 -----END PGP SIGNATURE-----
В списке pgsql-hackers по дате отправления: