Re: EvalPlanQual behaves oddly for FDW queries involving system columns - Mailing list pgsql-hackers

From Tom Lane
Subject Re: EvalPlanQual behaves oddly for FDW queries involving system columns
Date
Msg-id 10956.1431465737@sss.pgh.pa.us
Whole thread Raw
In response to Re: EvalPlanQual behaves oddly for FDW queries involving system columns  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: EvalPlanQual behaves oddly for FDW queries involving system columns  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers
I wrote:
> I did a very basic update of your postgres_fdw patch to test this with,
> and attach that so that you don't have to repeat the effort.  I'm not sure
> whether we want to try to convert that into something committable.  I'm
> afraid that the extra round trips involved in doing row locking this way
> will be so expensive that no one really wants it for postgres_fdw.  It's
> more credible that FDWs operating against local storage would have use
> for it.

Of course, if we don't do that then we still have your original gripe
about ctid not being correct in EvalPlanQual results.  I poked at this
a bit and it seems like we could arrange to pass ctid through even in
the ROW_MARK_COPY case, if we define the t_ctid field of a composite
Datum as being the thing to use.  The attached WIP, mostly-comment-free
patch seems to fix the original test case.  It would likely result in
ctid coming out as (0,0) not (4294967295,0) for FDWs that don't take
any special steps to return a valid ctid, as a result of the fact that
heap_form_tuple just leaves that field zeroed.  We could fix that by
adding an ItemPointerSetInvalid(&(td->t_ctid)) call to heap_form_tuple,
but I dunno if we want to add even a small number of cycles for this
purpose to such a core function.

            regards, tom lane

diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c
index 0c44260..2350de3 100644
*** a/contrib/postgres_fdw/postgres_fdw.c
--- b/contrib/postgres_fdw/postgres_fdw.c
*************** make_tuple_from_result_row(PGresult *res
*** 2965,2971 ****
--- 2965,2974 ----
      tuple = heap_form_tuple(tupdesc, values, nulls);

      if (ctid)
+     {
          tuple->t_self = *ctid;
+         tuple->t_data->t_ctid = *ctid;
+     }

      /* Clean up */
      MemoryContextReset(temp_context);
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 43d3c44..4c39e06 100644
*** a/src/backend/executor/execMain.c
--- b/src/backend/executor/execMain.c
*************** EvalPlanQualFetchRowMarks(EPQState *epqs
*** 2613,2621 ****

              /* build a temporary HeapTuple control structure */
              tuple.t_len = HeapTupleHeaderGetDatumLength(td);
-             ItemPointerSetInvalid(&(tuple.t_self));
              /* relation might be a foreign table, if so provide tableoid */
              tuple.t_tableOid = erm->relid;
              tuple.t_data = td;

              /* copy and store tuple */
--- 2613,2622 ----

              /* build a temporary HeapTuple control structure */
              tuple.t_len = HeapTupleHeaderGetDatumLength(td);
              /* relation might be a foreign table, if so provide tableoid */
              tuple.t_tableOid = erm->relid;
+             /* also copy t_ctid in case somebody supplied it */
+             tuple.t_self = td->t_ctid;
              tuple.t_data = td;

              /* copy and store tuple */

pgsql-hackers by date:

Previous
From: Eva7
Date:
Subject: Re: mogrify and indent features for jsonb
Next
From: Andres Freund
Date:
Subject: Re: Minor ON CONFLICT related fixes