On 2015/09/29 17:49, Kouhei Kaigai wrote:
From: pgsql-hackers-ow...@postgresql.org [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 quals*".
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.
Best regards, Etsuro Fujita -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
