Etsuro, * Etsuro Fujita (fujita.ets...@lab.ntt.co.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.
Thanks!
Stephen
signature.asc
Description: Digital signature
