From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Tim Bishop <tim(at)inroads(dot)ai> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Christoph Berg <myon(at)debian(dot)org>, Bernhard Übelacker <bernhardu(at)mailbox(dot)org> |
Subject: | Re: debian bugrept involving fast default crash in pg11.7 |
Date: | 2021-04-04 21:54:51 |
Message-ID: | 76234b03-2f03-b9d1-7d61-e0552ec8e872@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2021-04-04 22:08:02 | Re: Extensions not dumped when --schema is used |
Previous Message | Tomas Vondra | 2021-04-04 21:29:27 | Re: Autovacuum on partitioned table (autoanalyze) |