Re: Pending 9.4 patches

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Gregory Smith <gregsmithpgsql(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Pending 9.4 patches
Date: 2014-04-09 01:25:01
Message-ID: 5344A16D.7060003@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/09/2014 01:54 AM, Stephen Frost wrote:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> On Tue, Apr 8, 2014 at 11:59 AM, Gregory Smith
>> <gregsmithpgsql(at)gmail(dot)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-----

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-04-09 01:28:19 Re: Pending 9.4 patches
Previous Message Craig Ringer 2014-04-09 01:21:04 Re: Pending 9.4 patches