It is very hard to say, but I fear that there may be a disk level issue (corruption) and this table might be getting participating in the autovacuum process initial for these 2 crashes.
To reconfirm maybe you can verify by taking a logical dump for this particular table or whole database once if there any disk level or block level corruption, and it may be causing that test to be avoided from the fearing out during the tuning operation.
this morning my database crashed, because of a problem during autovacuum.
this is the second time during the last 2 month and i can't find out why.
logfile:
2018-12-28 10:52:22 CET [23757-59] LOG: Serverprozess (PID 14149) wurde von Signal 6 beendet: Aborted 2018-12-28 10:52:22 CET [23757-60] DETAIL: Der fehlgeschlagene Prozess führte aus: autovacuum: VACUUM ANALYZE public.planet_osm_ways 2018-12-28 10:52:22 CET [23757-61] LOG: aktive Serverprozesse werden abgebrochen 2018-12-28 10:52:23 CET [26335-1] postgres@planet3 FATAL: das Datenbanksystem ist im Wiederherstellungsmodus 2018-12-28 10:52:23 CET [23757-62] LOG: alle Serverprozesse beendet; initialisiere neu 2018-12-28 10:52:25 CET [26402-1] postgres@planet3 FATAL: das Datenbanksystem ist im Wiederherstellungsmodus 2018-12-28 10:52:25 CET [26401-1] LOG: Datenbanksystem wurde unterbrochen; letzte bekannte Aktion am 2018-12-28 10:50:10 CET
that's all i get :(
it is a really big table (552.669.751 records, 228 GB data + indices) and the last two autovacuum analyze did well. running for a really long time (> 2 days) but without any (known) problems.