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

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Tim Bishop <tim(at)inroads(dot)ai>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, 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: 2020-04-09 20:39:49
Message-ID: 20200409203949.GA26445@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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) ?

Thanks,
--
Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-04-09 20:56:03 Re: Catalog invalidations vs catalog scans vs ScanPgRelation()
Previous Message James Coleman 2020-04-09 20:37:33 Re: Multiple FPI_FOR_HINT for the same block during killing btree index items