From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Adam Scott <adam(dot)c(dot)scott(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16122: segfault pg_detoast_datum (datum=0x0) at fmgr.c:1833 numrange query |
Date: | 2019-11-19 11:40:56 |
Message-ID: | 20191119114056.GA516103@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, Nov 19, 2019 at 11:38:13AM +0100, Tomas Vondra wrote:
> FWIW I've managed to reproduce this on 10, but I had to build without
> --enable-cassert. So this does trigger the issue:
>
> Haven't investigated further yet.
If you add an ANALYZE on the table natica_hdu_test after restoring, I
am rather sure that you would reproduce the crash more quickly because
the handling around the stats of the column are busted here. Anyway,
taking my example of upthread, I have been also able to reproduce the
problem on REL_10_STABLE even with assertions enabled: the trick is
that you need to leave once the session after the analyze on the
table. Then a SELECT within a new session is enough to crash the
server.
The change with stdbool.h actually makes the crash easier to reproduce
as there is no need to leave the session. I am not sure how it
mattered..
[ ... And one bisect later ... ]
This looks more correct as culprit than the precedent because it
touches the area of the crash:
commit: 9aab83fc5039d83e84144b7bed3fb1d62a74ae78
author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
date: Sat, 13 May 2017 15:14:39 -0400
Redesign get_attstatsslot()/free_attstatsslot() for more safety and speed.
It seems to me that that we are simply free'ing an area which still
needs to be accessed for the stat estimations.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Manuel Rigger | 2019-11-19 12:50:51 | Failed assertion clauses != NIL |
Previous Message | Tomas Vondra | 2019-11-19 10:38:13 | Re: BUG #16122: segfault pg_detoast_datum (datum=0x0) at fmgr.c:1833 numrange query |