PostgreSQL Bugs

Collected from the PG bugs email list.

Bug ID16219
PG Version12.1
OSUbuntu 18.04
Opened2020-01-20 14:54:34+00
Reported byJulian Schauder

Body of first available message related to this bug follows.

The following bug has been logged on the website:

Bug reference:      16219
Logged by:          Julian Schauder
Email address:      (redacted)
PostgreSQL version: 12.1
Operating system:   Ubuntu 18.04

Howdy Hackers,

for a week now (upgrade pg11=>12) we're experiencing a bug that causes
segfaults on a daily basis. 
I've yet to reproduce this exact behaviour as the querys do not fail all the
time but rather now-and-then 
when run concurrently. ( ~4 Crashes so far )

Outputs(identifiers) are anonymised.

> 2020-01-20 01:39:24.246 CET [2112]  LOG:  server process (PID 31599) was
terminated by signal 11: Segmentation fault
> 2020-01-20 01:39:24.246 CET [2112]  DETAIL:  Failed process was running:
UPDATE partitionedtable ia SET A=A, B=now() FROM temptable tt WHERE AND A::text IS DISTINCT FROM tt.A::text;
> 2020-01-20 01:39:24.246 CET [2112]  LOG:  terminating any other active
server processes

> #0  EvalPlanQualFetchRowMark (epqstate=0x5576bfbccfc0, rti=2,
slot=slot@entry=0x5576c888b6c0) at
> #1  0x00005576bdf449ce in ExecScanFetch (recheckMtd=0x5576bdf65740
<SeqRecheck>, accessMtd=0x5576bdf656b0 <SeqNext>, node=0x5576c888b500) at
> #2  ExecScan (node=0x5576c888b500, accessMtd=0x5576bdf656b0 <SeqNext>,
recheckMtd=0x5576bdf65740 <SeqRecheck>) at
> #3  0x00005576bdf63f7d in ExecProcNode (node=0x5576c888b500) at
> #4  ExecNestLoop (pstate=<optimized out>) at
> #5  0x00005576bdf3e9a9 in ExecProcNode (node=0x5576c888b310) at
> #6  EvalPlanQualNext (epqstate=epqstate@entry=0x5576bfbccfc0) at
> #7  0x00005576bdf3ee77 in EvalPlanQual
relation=relation@entry=0x7fbfd57df168, rti=42,
inputslot=inputslot@entry=0x5576cfb66578) at ./build/../src/backend/>
> #8  0x00005576bdf61f5e in ExecUpdate
(mtstate=mtstate@entry=0x5576bfbccec8, tupleid=0x7ffdd552f89a, oldtuple=0x0,
slot=<optimized out>, planSlot=planSlot@entry=0x5576c153f428,
epqstate=epqstate@entry=0x5576bfbccfc0, estate=0x5576bf5df080, 
>     canSetTag=true) at
> #9  0x00005576bdf62df9 in ExecModifyTable (pstate=0x5576bfbccec8) at
> #10 0x00005576bdf3c23d in ExecProcNode (node=0x5576bfbccec8) at
> #11 ExecutePlan (execute_once=<optimized out>, dest=0x5576be63ec00
<donothingDR>, direction=<optimized out>, numberTuples=0,
sendTuples=<optimized out>, operation=CMD_UPDATE,
use_parallel_mode=<optimized out>, planstate=0x5576bfbccec8, 
>     estate=0x5576bf5df080) at
> #12 standard_ExecutorRun (queryDesc=0x5576bed15ae0, direction=<optimized
out>, count=0, execute_once=<optimized out>) at
> #13 0x00007fc89b1a4125 in pgss_ExecutorRun (queryDesc=0x5576bed15ae0,
direction=ForwardScanDirection, count=0, execute_once=<optimized out>) at
> #14 0x00005576be0993b5 in ProcessQuery (plan=<optimized out>, 
>     sourceText=0x5576bed159d0 "UPDATE partitionedtable ia SET A=A, B=now()
>     params=0x0, queryEnv=0x0, dest=0x5576be63ec00 <donothingDR>,
completionTag=0x7ffdd552ff40 "") at
> #15 0x00005576be0995f3 in PortalRunMulti
(portal=portal@entry=0x5576bea978f0, isTopLevel=isTopLevel@entry=true,
setHoldSnapshot=setHoldSnapshot@entry=false, dest=0x5576be63ec00
<donothingDR>, dest@entry=0x5576bea00890, 
>     altdest=0x5576be63ec00 <donothingDR>, altdest@entry=0x5576bea00890,
completionTag=completionTag@entry=0x7ffdd552ff40 "") at
> #16 0x00005576be09a1ff in PortalRun (portal=portal@entry=0x5576bea978f0,
count=count@entry=1, isTopLevel=isTopLevel@entry=true, run_once=<optimized
out>, dest=dest@entry=0x5576bea00890, altdest=altdest@entry=0x5576bea00890,

>     completionTag=0x7ffdd552ff40 "") at
> #17 0x00005576be097a31 in exec_execute_message (max_rows=1,
portal_name=0x5576bea00480 "") at
> #18 PostgresMain (argc=<optimized out>, argv=argv@entry=0x5576bea2fbd0,
dbname=<optimized out>, username=<optimized out>) at
> #19 0x00005576be01e53b in BackendRun (port=0x5576bea27dc0,
port=0x5576bea27dc0) at
> #20 BackendStartup (port=0x5576bea27dc0) at
> #21 ServerLoop () at ./build/../src/backend/postmaster/postmaster.c:1704
> #22 0x00005576be01f513 in PostmasterMain (argc=5, argv=0x5576be9f9090) at
> #23 0x00005576bdd95cf6 in main (argc=5, argv=0x5576be9f9090) at

> #0  EvalPlanQualFetchRowMark (epqstate=0x5576bfbccfc0, rti=2,
slot=slot@entry=0x5576c888b6c0) at
>         earm = 0x5576c7176258
>         erm = 0x24
>         datum = <optimized out>
>         isNull = false
>         __func__ = "EvalPlanQualFetchRowMark"
> #1  0x00005576bdf449ce in ExecScanFetch (recheckMtd=0x5576bdf65740
<SeqRecheck>, accessMtd=0x5576bdf656b0 <SeqNext>, node=0x5576c888b500) at
>         slot = 0x5576c888b6c0
>         epqstate = <optimized out>
>         scanrelid = <optimized out>
>         slot = <optimized out>
>         estate = 0x5576c888b100
>         estate = <optimized out>
>         epqstate = <optimized out>
>         scanrelid = <optimized out>
>         slot = <optimized out>
>         slot = <optimized out>
>         slot = <optimized out>
>         slot = <optimized out>
> #2  ExecScan (node=0x5576c888b500,

Excerpt shows the pointer 0x24 of erm to be uninitialized'ish. Once i can
capture a second 
stacktrace i might be able to confirm if this is indeed a random value or
always 0x24. However,
we're workarounding this by simply not running this query concurrently
anymore hence i might
lack new stacktraces soon.

> UPDATE partitionedtable ia SET A=A, B=now() FROM temptable tt WHERE AND A::text IS DISTINCT FROM tt.A::text;
>                                                           QUERY PLAN      
>  Update on partitionedtable ia  (cost=0.43..1202173.35 rows=465660
>    Update on partitionedtable ia
>    Update on partitionedtable_0062 ia_1
>    Update on partitionedtable_0061 ia_2
>    Update on partitionedtable_0060 ia_3
> [repeats for another ~400 Partitions]
> [..]
>    ->  Nested Loop  (cost=0.43..3386.78 rows=1194 width=145)
>          ->  Seq Scan on temptable tt  (cost=0.00..22.00 rows=1200
>          ->  Index Scan using partitionedtable_pk on partitionedtable ia 
(cost=0.43..2.79 rows=1 width=560)
>                Index Cond: (id = tt.ia_id)
>                Filter: ((document)::text IS DISTINCT FROM
>    ->  Nested Loop  (cost=0.42..3108.99 rows=1194 width=159)
>          ->  Seq Scan on temptable tt  (cost=0.00..22.00 rows=1200
>          ->  Index Scan using partitionedtable_062_pk on
partitionedtable_0062 ia_1  (cost=0.42..2.56 rows=1 width=518)
>                Index Cond: (id = tt.ia_id)
>                Filter: ((document)::text IS DISTINCT FROM
> [repeats for another ~400 Partitions]
> [..]
>  JIT:
>    Functions: 3510
>    Options: Inlining true, Optimization true, Expressions true, Deforming
> (2344 rows)

The Query basically updates a massively partitioned* Table from the
of a temptable.

*Inheritance-Partitioning on ID(not modified within the query)
*Inheritance has triggers. ISTM that they are not of any concern.

System is a current Ubuntu18.04 with a freshly pg_upgrade'd postgresql-12.1
including new statistics, indices and vacuum.

I'm currently trying to get this to a minimized and reproducible form as i
do not see an 
obvious error in the code yet. For the time being i fail to actually
recreate as accurate as 
production does :)



2020-01-20 14:54:34+00PG Bug reporting formBUG #16219: EvalPlanQualFetchRowMark segfaults on Updates
2020-01-20 16:14:26+00Tom LaneRe: BUG #16219: EvalPlanQualFetchRowMark segfaults on Updates