On 2015/09/29 17:49, Kouhei Kaigai wrote:
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita
RefetchForeignRow() does not take ForeignScanState as its argument,
so it is not obvious to access its private field, isn't it?
ExecRowMark contains "rti" field, so it might be feasible to find out
the target PlanState using walker routine recently supported, although
it is not a simple enough.
Unless we don't have reference to the private field, it is not feasible
to access expression that was pushed down to the remote-side, therefore,
it does not allow to apply proper rechecks here.
Could you introduce us (1) how to access private data field of
ForeignScanState from the RefetchForeignRow callback?
For the foreign table case (scanrelid>0), I imagined an approach
different than yours. In that case, I thought the issue would be
probably addressed by just modifying the remote query performed in
RefetchForeignRow, which would be of the form "SELECT ctid, * FROM
remote table WHERE ctid = $1", so that the modified query would be of
the form "SELECT ctid, * FROM remote table WHERE ctid = $1 AND *remote
Sorry, I forgot to add "FOR UPDATE" to the before/after queries.
My question is how to pull expression of the remote query.
It shall be stored at somewhere private field of ForeignScanState,
however, RefetchForeignRow does not have direct access to the
relevant ForeignScanState node.
It is what I asked at the question (1).
I imagined the following steps to get the remote query string: (1)
create the remote query string and store it in fdw_private during
postgresGetForeignPlan, (2) extract the string from fdw_private and
store it in erm->ermExtra during postgresBeginForeignScan, and (3)
extract the string from erm->ermExtra in postgresRefetchForeignRow.
Also note that EvalPlanQualFetchRowMarks() will raise an error
if RefetchForeignRow callback returned NULL tuple.
Is it right or expected behavior?
IIUC, I think that that behavior is reasonable.
It looks to me this callback is designed to pull out a particular
tuple identified by the remote-row-id, regardless of the qualifier
checks based on the latest value.
Because erm->markType==ROW_MARK_REFERENCE, I don't think that that
behavior would cause any problem. Maybe I'm missing something, though.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: