Fix order of operations in ExecEvalFieldStoreDeForm().

If the given composite datum is toasted out-of-line,
DatumGetHeapTupleHeader will perform database accesses to detoast it.
That can invalidate the result of get_cached_rowtype, as documented
(perhaps not plainly enough) in that function's API spec; which leads
to strange errors or crashes when we try to use the TupleDesc to read
the tuple.  In short then, trying to update a field of a composite
column could fail intermittently if the overall column value is wide
enough to require toasting.

We can fix the bug at no cost by just changing the order of
operations, since we don't need the TupleDesc until after detoasting.
(Other callers of get_cached_rowtype appear to get this right already,
so there's only one bug.)

Note that the added regression test case reveals this bug reliably
only with debug_discard_caches/CLOBBER_CACHE_ALWAYS.

Per bug #17994 from Alexander Lakhin.  Sadly, this patch does not fix
the missing-values issue revealed in the bug discussion; we'll need
some more work to cover that.

Discussion: https://postgr.es/m/17994-5c7100b51b4790e9@postgresql.org

diff --git a/src/backend/executor/execExprInterp.c b/src/backend/executor/execExprInterp.c
index bdf59a10fcfec3f2756dee6bfe68ac33633ac691..4b2c48ba602d73a98ee114ae15af32feeaec2c03 100644 (file)
--- a/src/backend/executor/execExprInterp.c
+++ b/src/backend/executor/execExprInterp.c
@@ -1969,7 +1969,8 @@ CheckOpSlotCompatibility(ExprEvalStep *op, TupleTableSlot *slot)
  * changed: if not NULL, *changed is set to true on any update
  *
  * The returned TupleDesc is not guaranteed pinned; caller must pin it
- * to use it across any operation that might incur cache invalidation.
+ * to use it across any operation that might incur cache invalidation,
+ * including for example detoasting of input tuples.
  * (The TupleDesc is always refcounted, so just use IncrTupleDescRefCount.)
  *
  * NOTE: because composite types can change contents, we must be prepared
@@ -3128,17 +3129,6 @@ ExecEvalFieldSelect(ExprState *state, ExprEvalStep *op, ExprContext *econtext)
 void
 ExecEvalFieldStoreDeForm(ExprState *state, ExprEvalStep *op, ExprContext *econtext)
 {
-   TupleDesc   tupDesc;
-
-   /* Lookup tupdesc if first time through or if type changes */
-   tupDesc = get_cached_rowtype(op->d.fieldstore.fstore->resulttype, -1,
-                                op->d.fieldstore.rowcache, NULL);
-
-   /* Check that current tupdesc doesn't have more fields than we allocated */
-   if (unlikely(tupDesc->natts > op->d.fieldstore.ncolumns))
-       elog(ERROR, "too many columns in composite type %u",
-            op->d.fieldstore.fstore->resulttype);
-
    if (*op->resnull)
    {
        /* Convert null input tuple into an all-nulls row */
@@ -3154,6 +3144,7 @@ ExecEvalFieldStoreDeForm(ExprState *state, ExprEvalStep *op, ExprContext *econte
        Datum       tupDatum = *op->resvalue;
        HeapTupleHeader tuphdr;
        HeapTupleData tmptup;
+       TupleDesc   tupDesc;
 
        tuphdr = DatumGetHeapTupleHeader(tupDatum);
        tmptup.t_len = HeapTupleHeaderGetDatumLength(tuphdr);
@@ -3161,6 +3152,20 @@ ExecEvalFieldStoreDeForm(ExprState *state, ExprEvalStep *op, ExprContext *econte
        tmptup.t_tableOid = InvalidOid;
        tmptup.t_data = tuphdr;
 
+       /*
+        * Lookup tupdesc if first time through or if type changes.  Because
+        * we don't pin the tupdesc, we must not do this lookup until after
+        * doing DatumGetHeapTupleHeader: that could do database access while
+        * detoasting the datum.
+        */
+       tupDesc = get_cached_rowtype(op->d.fieldstore.fstore->resulttype, -1,
+                                    op->d.fieldstore.rowcache, NULL);
+
+       /* Check that current tupdesc doesn't have more fields than allocated */
+       if (unlikely(tupDesc->natts > op->d.fieldstore.ncolumns))
+           elog(ERROR, "too many columns in composite type %u",
+                op->d.fieldstore.fstore->resulttype);
+
        heap_deform_tuple(&tmptup, tupDesc,
                          op->d.fieldstore.values,
                          op->d.fieldstore.nulls);

diff --git a/src/test/regress/expected/rowtypes.out b/src/test/regress/expected/rowtypes.out
index a4cc2d8c126341dcef8bea1c8ab65e21baa080b9..4a05a730d96c23f7b33e7351cc7a6ef9d46cbf08 100644 (file)
--- a/src/test/regress/expected/rowtypes.out
+++ b/src/test/regress/expected/rowtypes.out
@@ -145,6 +145,15 @@ select (fn).first, substr((fn).last, 1, 20), length((fn).last) from people;
  Jim   | abcdefghijklabcdefgh | 1200000
 (2 rows)
 
+-- try an update on a toasted composite value, too
+update people set fn.first = 'Jack';
+select (fn).first, substr((fn).last, 1, 20), length((fn).last) from people;
+ first |        substr        | length  
+-------+----------------------+---------
+ Jack  | Blow                 |       4
+ Jack  | abcdefghijklabcdefgh | 1200000
+(2 rows)
+
 -- Test row comparison semantics.  Prior to PG 8.2 we did this in a totally
 -- non-spec-compliant way.
 select ROW(1,2) < ROW(1,3) as true;

diff --git a/src/test/regress/sql/rowtypes.sql b/src/test/regress/sql/rowtypes.sql
index ad5b7e128f956ba1bb6b6f74023fba0e3b0bd80e..2ea5e25525aff349381b7cc2686b52effc78bae4 100644 (file)
--- a/src/test/regress/sql/rowtypes.sql
+++ b/src/test/regress/sql/rowtypes.sql
@@ -80,6 +80,11 @@ insert into people select ('Jim', f1, null)::fullname, current_date from pp;
 
 select (fn).first, substr((fn).last, 1, 20), length((fn).last) from people;
 
+-- try an update on a toasted composite value, too
+update people set fn.first = 'Jack';
+
+select (fn).first, substr((fn).last, 1, 20), length((fn).last) from people;
+
 -- Test row comparison semantics.  Prior to PG 8.2 we did this in a totally
 -- non-spec-compliant way.