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
