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
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) |