Fujita-san, > On 2015/07/22 19:10, Etsuro Fujita wrote: > > While working on the issue "Foreign join pushdown vs EvalPlanQual", I > > happened to notice odd behaviors of late row locking in FDWs. > > > I think the reason for that is because we don't check pushed-down quals > > inside an EPQ testing even if what was fetched by RefetchForeignRow was > > an updated version of the tuple rather than the same version previously > > obtained. So, to fix this, I'd like to propose that pushed-down quals > > be checked in ForeignRecheck. > > Attached is a patch for that. > > * I've modified ForeignRecheck so as to check pushed-down quals whether > doing late locking or early locking. I think we could probably make > ForeignRecheck do so only when doing late locking, but I'm not sure it's > worth complicating the code. > > * I've made the above change only for simple foreign table scans that > have scanrelid > 0 and fdw_scan_tlist = NIL. As for simple foreign > table scans that have scanrelid > 0 and *fdw_scan_tlist is non-NIL*, I > think we are under discussion in another thread I started. Will update > as necessary. > > * Sorry, I've not fully updated comments and docs yet. Will update. > > I'd be happy if I could get feedback earlier. > Isn't it an option to put a new callback in ForeignRecheck?
FDW driver knows its private data structure includes expression node that was pushed down to the remote side. So, it seems to me the best way to consult FDW driver whether the supplied tuple should be visible according to the pushed down qualifier. More or less, this fix need a new interface contract around EvalPlanQual logic. It is better to give FDW driver more flexibility of its private data structure and the way to process recheck logic, rather than special purpose variable. If FDW driver managed pushed-down expression in its own format, requirement to pushedDownQual makes them to have qualifier redundantly. The callback approach does not have such kind of concern. Thanks, -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers