From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org >> PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Odd behavior of updatable security barrier views on foreign tables |
Date: | 2015-02-13 05:36:00 |
Message-ID: | 54DD8D40.6030507@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015/02/11 4:06, Stephen Frost wrote:
> * Etsuro Fujita (fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp) wrote:
>> On 2015/02/10 7:23, Dean Rasheed wrote:
>>> Sorry, I didn't have time to look at this properly. My initial thought
>>> is that expand_security_qual() needs to request a lock on rows coming
>> >from the relation it pushes down into a subquery if that relation was
>>> the result relation, because otherwise it won't have any locks, since
>>> preprocess_rowmarks() only adds PlanRowMarks to non-target relations.
>>
>> That seems close to what I had in mind; expand_security_qual() needs
>> to request a FOR UPDATE lock on rows coming from the relation it
>> pushes down into a subquery only when that relation is the result
>> relation and *foreign table*.
>
> I had been trying to work out an FDW-specific way to address this, but I
> think Dean's right that this should be addressed in
> expand_security_qual(), which means it'll apply to all cases and not
> just these FDW calls. I don't think that's actually an issue though and
> it'll match up to how SELECT FOR UPDATE is handled today.
Sorry, my explanation was not accurate, but I also agree with Dean's
idea. In the above, I just wanted to make it clear that such a lock
request done by expand_security_qual() should be limited to the case
where the relation that is a former result relation is a foreign table.
If it's OK, I'll submit a patch for that, maybe early next week.
Thank you for working on this issue!
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-02-13 05:47:06 | Re: [REVIEW] Re: Compression of full-page-writes |
Previous Message | Tom Lane | 2015-02-13 05:27:04 | "multiple backends attempting to wait for pincount 1" |