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
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 ?
SELECT attrelid::regclass, * FROM pg_attribute WHERE atthasmissing;
-[ RECORD 1 ]-+-
attrelid | download
attrelid | 22749
attname | filetype
atttypid | 1043
attstattarget | -1
attlen| -1
attnum| 5
attndims | 0
attcacheoff | -1
atttypmod | 36
I've attached a file containing the \d+ for all the tables involved and
the EXPLAIN ANALYZE for the query.
Yes, the crash happened under v11.6. I had tried downgrading when I
first encountered the problem.
While trying to put together this information the crash started
happening less
On Thu, Apr 09, 2020 at 02:05:22PM -0400, Tim Bishop wrote:
> I've attached a file containing the \d+ for all the tables involved and the
> EXPLAIN ANALYZE for the query.
Thanks for your response.
Do you know if you used the "fast default feature" ?
That would happen if you did "ALTER TABLE tbl
I happened across this bugreport, which seems to have just enough information
to be interesting.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953204
|Version: 11.7-0+deb10u1
|2020-03-05 16:55:55.511 UTC [515] LOG: background worker "parallel worker"
(PID 884) was terminated by signal 11:
