Re: BUG #15815: Upgraded from 9.6.8 > 9.6.12 on AWS Aurora: SELECTscausing segmentation fault
От | Steve |
---|---|
Тема | Re: BUG #15815: Upgraded from 9.6.8 > 9.6.12 on AWS Aurora: SELECTscausing segmentation fault |
Дата | |
Msg-id | CAJr1J1eB6L_uDch4SGj2cCHdSrKMQUFW2_WvM1GGmG3Z+Oot8A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #15815: Upgraded from 9.6.8 > 9.6.12 on AWS Aurora: SELECTs causing segmentation fault (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #15815: Upgraded from 9.6.8 > 9.6.12 on AWS Aurora: SELECTs causing segmentation fault
|
Список | pgsql-bugs |
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󜊏
On Tue, May 21, 2019 at 9:43 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Steve <postgres-ca@byrequest.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
В списке pgsql-bugs по дате отправления: