Re: SegFault on 9.6.14
Tomas Vondra <tomas.vondra@2ndquadrant.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Jerry Sievers <gsievers19@comcast.net>
Cc: pgsql-hackers@postgresql.org
Date: 2019-07-16T00:15:29Z
Lists: pgsql-hackers
On Mon, Jul 15, 2019 at 06:48:05PM -0500, Jerry Sievers wrote:
>Greetings Hackers.
>
>We have a reproduceable case of $subject that issues a backtrace such as
>seen below.
>
>The query that I'd prefer to sanitize before sending is <30 lines of at
>a glance, not terribly complex logic.
>
>It nonetheless dies hard after a few seconds of running and as expected,
>results in an automatic all-backend restart.
>
>Please advise on how to proceed. Thanks!
>
>bt
>#0 initscan (scan=scan@entry=0x55d7a7daa0b0, key=0x0, keep_startblock=keep_startblock@entry=1 '\001')
> at /build/postgresql-9.6-5O8OLM/postgresql-9.6-9.6.14/build/../src/backend/access/heap/heapam.c:233
>#1 0x000055d7a72fa8d0 in heap_rescan (scan=0x55d7a7daa0b0, key=key@entry=0x0) at /build/postgresql-9.6-5O8OLM/postgresql-9.6-9.6.14/build/../src/backend/access/heap/heapam.c:1529
>#2 0x000055d7a7451fef in ExecReScanSeqScan (node=node@entry=0x55d7a7d85100) at /build/postgresql-9.6-5O8OLM/postgresql-9.6-9.6.14/build/../src/backend/executor/nodeSeqscan.c:280
>#3 0x000055d7a742d36e in ExecReScan (node=0x55d7a7d85100) at /build/postgresql-9.6-5O8OLM/postgresql-9.6-9.6.14/build/../src/backend/executor/execAmi.c:158
>#4 0x000055d7a7445d38 in ExecReScanGather (node=node@entry=0x55d7a7d84d30) at /build/postgresql-9.6-5O8OLM/postgresql-9.6-9.6.14/build/../src/backend/executor/nodeGather.c:475
>#5 0x000055d7a742d255 in ExecReScan (node=0x55d7a7d84d30) at /build/postgresql-9.6-5O8OLM/postgresql-9.6-9.6.14/build/../src/backend/executor/execAmi.c:166
>#6 0x000055d7a7448673 in ExecReScanHashJoin (node=node@entry=0x55d7a7d84110) at /build/postgresql-9.6-5O8OLM/postgresql-9.6-9.6.14/build/../src/backend/executor/nodeHashjoin.c:1019
>#7 0x000055d7a742d29e in ExecReScan (node=node@entry=0x55d7a7d84110) at /build/postgresql-9.6-5O8OLM/postgresql-9.6-9.6.14/build/../src/backend/executor/execAmi.c:226
><about 30 lines omitted>
>
Hmmm, that means it's crashing here:
if (scan->rs_parallel != NULL)
scan->rs_nblocks = scan->rs_parallel->phs_nblocks; <--- here
else
scan->rs_nblocks = RelationGetNumberOfBlocks(scan->rs_rd);
But clearly, scan is valid (otherwise it'd crash on the if condition),
and scan->rs_parallel must me non-NULL. Which probably means the pointer
is (no longer) valid.
Could it be that the rs_parallel DSM disappears on rescan, or something
like that?
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Don't shut down Gather[Merge] early under Limit.
- 1ad0df67c790 9.6.17 landed
- f7ae68aacd9d 10.12 landed
- d0ccfa9d6a3d 11.7 landed
- 1cc3a90c7551 12.2 landed
- 080313f8296f 13.0 landed
-
Prohibit shutting down resources if there is a possibility of back up.
- 2cd0acfdade8 12.0 cited
-
Fix buffer usage stats for parallel nodes.
- 19df1702f5c5 9.6.10 cited
- 85c9d3475e4f 12.0 cited
-
Fix crashes on plans with multiple Gather (Merge) nodes.
- fd7c0fa732d9 11.0 cited
-
Separate reinitialization of shared parallel-scan state from ExecReScan.
- 41b0dd987d44 11.0 cited