I recall seeing various discussions hoping that it'd been finally fixed - Just wanted to report that this has happened now under postgres 10.4. It looks like this is not related to: 0408e1ed599b06d9bca2927a50a4be52c9e74bb9 which is for "unexpected chunk number" (?) Note that this is on the postgres database, which I think is where I saw it on one of our internal VMs in the past (althought my memory indicates that may have affected multiple DBs). In the immediate case, this is customer's centos6 VM running under qemu/KVM: the same configuration as our internal VM which had this issue (I just found a ticket dated 2016-10-06). In case it helps: - the postgres database has a few things in it, primarily imported CSV logs. On this particular server, there's actually a 150GB table with old CSV logs from an script I fixed recently to avoid saving many lines than intended (something like for each session_id every session_line following an error_severity!='LOG') - I also have copies of pg_stat_bgwriter, pg_settings, and an aggregated copy of pg_buffercache here. - nagios: some scripts loop around all DBs; some maybe connect directly to postgres (for example, to list DBs). However, I don't think check_postgres probably doesn't connect to postgres DB. I'll defer fixing this for awhile in case someone wants me to save a copy of the relation/toast/index. From last time, I recall this just needs the right combination of REINDEX/VACUUM/ANALYZE, and the only complication was me needing to realize the right combination of affected DB(s). Thanks, Justin
