Re: debian bugrept involving fast default crash in pg11.7

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

In response to

Browse pgsql-hackers by date

  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)