Andreas Seltenreich <seltenreich@gmx.de> writes:
> Tom Lane writes:
>> What concerns me more is that what you're finding is only cases that trip
>> an assertion sanity check. It seems likely that you're also managing to
>> trigger other bugs with less drastic consequences, such as "could not
>> devise a query plan" failures or just plain wrong answers.
> Ja, some of these are logged as well[1], but most of them are really as
> undrastic as can get, and I was afraid reporting them would be more of a
> nuisance.
Well, I certainly think all of these represent bugs:
> 3 | ERROR: plan should not reference subplan's variable
> 2 | ERROR: failed to assign all NestLoopParams to plan nodes
> 1 | ERROR: could not find pathkey item to sort
This I'm not sure about; it could be that the query gave conflicting
collation specifiers, but on the other hand we've definitely had bugs
with people forgetting to run assign_query_collations on subexpressions:
> 4646 | ERROR: could not determine which collation to use for string comparison
This one's pretty darn odd, because 2619 is pg_statistic and not an index
at all:
> 4 | ERROR: cache lookup failed for index 2619
These seem likely to be bugs as well, though maybe they are race
conditions during a DROP and not worth fixing:
> 1171 | ERROR: cache lookup failed for index 16862
> 172 | ERROR: cache lookup failed for index 257148
> 84 | ERROR: could not find member 1(34520,34520) of opfamily 1976
> 55 | ERROR: missing support function 1(34516,34516) in opfamily 1976
> 13 | ERROR: could not find commutator for operator 34538
> 2 | ERROR: cache lookup failed for index 12322
I would say anything of the sort that is repeatable definitely deserves
investigation, because even if it's an expectable error condition, we
should be throwing a more user-friendly error message.
regards, tom lane
