Re: We need to support ForeignRecheck for late row locking, don't we?

KaiGai-san,

On 2015/07/24 23:51, Kouhei Kaigai wrote:
>> 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.

>> * I've modified ForeignRecheck so as to check pushed-down quals whether
>> doing late locking or early locking.

> 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.

That might be an idea, but is there any performance disadvantage as
discussed in [1]?; it looks like that that needs to perform another
remote query to see if the supplied tuple satisfies the pushed-down
quals during EPQ testing.

Best regards,
Etsuro Fujita

[1] http://www.postgresql.org/message-id/5590ED5C.2040200@lab.ntt.co.jp