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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bezverhijs Eduards <Eduards(dot)Bezverhijs(at)tieto(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: segmentation fault with simple UPDATE statement (postgres 10.5)
Date: 2018-12-12 17:16:16
Message-ID: 20181212171616.6kxyhcf4hwllff5k@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On 2018-12-12 11:13:17 -0500, Tom Lane wrote:
> Bezverhijs Eduards <Eduards(dot)Bezverhijs(at)tieto(dot)com> writes:
> > We encountered a bug in our systems with update statement, but long story short, here's the self-containing test case which 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2018-12-12 17:53:58 Re: segmentation fault with simple UPDATE statement (postgres 10.5)
Previous Message Tom Lane 2018-12-12 17:10:29 Re: segmentation fault with simple UPDATE statement (postgres 10.5)