Re: segmentation fault with simple UPDATE statement (postgres 10.5)

Hi,

On 2018-12-12 11:13:17 -0500, Tom Lane wrote:
> Bezverhijs Eduards <Eduards.Bezverhijs@tieto.com> writes:
> > We encountered a bug in our systems with update statement, but long story short, here's the self-containing test
casewhich results in segmentation fault.
 
>
> Huh.  I can reproduce this in 9.6 and 10, but not earlier or later
> branches.  Looking ...

Based on a relatively quick look it looks to me that crashing/no
crashing is a question of plan shape, rather than a bugfix.

The subplan is:
   {TARGETENTRY
   :expr
      {SUBPLAN
      :subLinkType 5
      :testexpr <>
      :paramIds <>
      :plan_id 1
      :plan_name SubPlan\ 1\ \(returns\ $1\)
      :firstColType 1043
      :firstColTypmod 5
      :firstColCollation 100
      :useHashTable false
      :unknownEqFalse false
      :parallel_safe false
      :setParam (i 1)
      :parParam (i 0)
      :args (
         {VAR
         :varno 1
         :varattno 1
         :vartype 1043
         :vartypmod 5
         :varcollid 100
         :varlevelsup 0
         :varnoold 1
         :varoattno 1
         :location 55
         }
      )
      :startup_cost 0.00
      :per_call_cost 38.25
      }
   :resno 2
   :resname <>
   :ressortgroupref 0
   :resorigtbl 0
   :resorigcol 0
   :resjunk true
   }

with varno still referencing a specific varno, rather than INNER/OUTER.
That works for master:
┌─────────────────────────────────────────────────────────────────────────┐
│                               QUERY PLAN                                │
├─────────────────────────────────────────────────────────────────────────┤
│ Update on public.t1  (cost=0.00..86477.60 rows=2260 width=46)           │
│   ->  Seq Scan on public.t1  (cost=0.00..86477.60 rows=2260 width=46)   │
│         Output: $1, (SubPlan 1 (returns $1)), t1.ctid                   │
│         SubPlan 1 (returns $1)                                          │
│           ->  Seq Scan on public.t2  (cost=0.00..38.25 rows=11 width=8) │
│                 Output: t2.b                                            │
│                 Filter: ((t2.b)::text = (t1.a)::text)                   │
└─────────────────────────────────────────────────────────────────────────┘

where the subplan is executed as a child of a seqscan, which thus has
ecxt_scantuple set.

But in 10:
┌───────────────────────────────────────────────────────────────────────────────┐
│                                  QUERY PLAN                                   │
├───────────────────────────────────────────────────────────────────────────────┤
│ Update on public.t1  (cost=0.00..86477.60 rows=2260 width=46)                 │
│   ->  Result  (cost=0.00..86477.60 rows=2260 width=46)                        │
│         Output: $1, ((SubPlan 1 (returns $1))), t1.ctid                       │
│         One-Time Filter: ('X'::text <> ALL ('{Y,Z}'::text[]))                 │
│         ->  Seq Scan on public.t1  (cost=0.00..86477.60 rows=2260 width=46)   │
│               Output: $1, (SubPlan 1 (returns $1)), t1.ctid                   │
│               SubPlan 1 (returns $1)                                          │
│                 ->  Seq Scan on public.t2  (cost=0.00..38.25 rows=11 width=8) │
│                       Output: t2.b                                            │
│                       Filter: ((t2.b)::text = (t1.a)::text)                   │
└───────────────────────────────────────────────────────────────────────────────┘

the subplan is executed below a Result node, which won't have scantuple
set. Therefore we crash.

Looking as to why that reference isn't corrected.

Greetings,

Andres Freund