On Wed, Aug 07, 2019 at 04:51:54PM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-08-07 14:29:28 -0500, Justin Pryzby wrote:
> > Just found this, although I'm not sure what to do about it. If it's corrupt
> > table data, I can restore from backup.
In the meantime, I've renamed+uninherited the
Hi,
On 2019-08-07 14:29:28 -0500, Justin Pryzby wrote:
> Just found this, although I'm not sure what to do about it. If it's corrupt
> table data, I can restore from backup.
>
> ts=# VACUUM FREEZE VERBOSE child.huawei_umts_ucell_201908;
> INFO: 0: aggressively vacuuming
Just found this, although I'm not sure what to do about it. If it's corrupt
table data, I can restore from backup.
ts=# VACUUM FREEZE VERBOSE child.huawei_umts_ucell_201908;
INFO: 0: aggressively vacuuming "child.huawei_umts_ucell_201908"
LOCATION: lazy_scan_heap, vacuumlazy.c:502
ERROR:
I checked this still happens with max_parallel_workers_per_gather=0.
Now, I just reproduced using SELECT * FROM that table:
(gdb) p thisatt->attrelid
$4 = 2015128626
ts=# SELECT 2015128626::regclass;
regclass | child.huawei_umts_ucell_201908
(gdb) p thisatt->attnum
$1 = 2
(gdb) p attnum # For
A daily report crashed repeatedly this morning running pg11.4.
I compiled 11.5 and reproduced it there, too, so I'm including backtrace with
-O0.
I'm trying to dig further into it, but it seems to be crashing under load, but
not when I try to narrow down to a single report, which seem to run to
