Re: debian bugrept involving fast default crash in pg11.7
От | Andrew Dunstan |
---|---|
Тема | Re: debian bugrept involving fast default crash in pg11.7 |
Дата | |
Msg-id | 76234b03-2f03-b9d1-7d61-e0552ec8e872@dunslane.net обсуждение исходный текст |
Ответ на | Re: debian bugrept involving fast default crash in pg11.7 (Justin Pryzby <pryzby@telsasoft.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: