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