Re: BUG #15815: Upgraded from 9.6.8 > 9.6.12 on AWS Aurora: SELECTs causing segmentation fault

Yeah I agree, and it is, ... our first step was to regenerate all the
indexes, but the segfault persists.

We're reproducing the case in a restored-from-snapshot db. Perhaps I'll
reindex again there. Since we have a AWS snapshot we can jump back pretty
fast to retest.

BINGO, An AWS Development Manager just stepped in… They've identified the
problem and deploying a patch release
https://forums.aws.amazon.com/thread.jspa?messageID=901775&#901775

On Tue, May 21, 2019 at 9:43 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Steve <postgres-ca(at)byrequest(dot)com> writes:
> > Column | Type | Modifiers
> >
> ----------------+---------+------------------------------------------------------
> > a | integer | not null default
> > nextval('{table3}_seq'::regclass)
> > b | integer |
> > c | integer |
> > d | text |
> > Indexes:
> > … PRIMARY KEY, btree (a)
> > … UNIQUE CONSTRAINT, btree (b, c)
> > … btree (b)
> > … btree (c)
> > … btree (lower("substring"(d, 1, 1000)) text_pattern_ops, b)
> > … btree (lower("substring"(d, 1, 1000)), b)
> > Foreign-key constraints:
> > … FOREIGN KEY (b) REFERENCES {table2}(b)
> > … FOREIGN KEY (c) REFERENCES {table1}(c)
>
> Hm, so this query is probably using the last of those indexes ---
> could we see EXPLAIN output to confirm that?
>
> If so, a plausible explanation is that a portion of that index is corrupt,
> although it's certainly not very nice that you're getting a crash rather
> than an error report.
>
> If you're in a hurry to restore functionality, dropping and recreating
> that index would likely make the problem go away ... but it would also
> destroy the evidence we'd need to find the cause of the crash. So if
> you can hold off till we see the stack trace, that'd be nice.
>
> regards, tom lane
>