On 4/9/20 4:39 PM, Justin Pryzby wrote:
> On Thu, Apr 09, 2020 at 02:36:26PM -0400, Tim Bishop wrote:
>> SELECT attrelid::regclass, * FROM pg_attribute WHERE atthasmissing;
>> -[ RECORD 1 ]-+---------
>> attrelid | download
>> attrelid | 22749
>> attname | filetype
> But that table isn't involved in the crashing query, right ?
> Are data_stage() and income_index() locally defined functions ? PLPGSQL ??
> Do they access the download table (or view or whatever it is) ?
>
As requested I have reviewed this old thread. You are correct, this
table is not involved in the query. That doesn't mean that the changes
made by the fast default code haven't caused a problem, but it makes it
a bit less likely. If the OP is still interested and can provide a
self-contained recipe to reproduce the problem I can investigate.
Without that it's difficult to know what to look at.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
