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 <kaigai@ak.jp.nec.com>