> Проверить железо и перестроить таблицу в новом физически месте. Похоже,
> предположение про неисправность стораджа верно.
имеется реплика теоретически можно попробовать на него переключиться,
но интересно на реплике не будет ли та же проблема.
посмотрел в обновлениях 9.5 (стоял 9.5.4) есть такие вещи в
чейнджлоге:
9.5.5
+ Fix WAL-logging of truncation of relation free space maps and visibility
maps (Pavan Deolasee, Heikki Linnakangas)
It was possible for these files to not be correctly restored during
crash recovery, or to be written incorrectly on a standby server. Bogus
entries in a free space map could lead to attempts to access pages that
have been truncated away from the relation itself, typically producing
errors like could not read block XXX: read only 0 of 8192 bytes.
Checksum failures in the visibility map are also possible, if
checksumming is enabled.
9.5.6
+ Fix a race condition that could cause indexes built with CREATE INDEX
CONCURRENTLY to be corrupt (Pavan Deolasee, Tom Lane)
If CREATE INDEX CONCURRENTLY was used to build an index that depends on
a column not previously indexed, then rows inserted or updated by
transactions that ran concurrently with the CREATE INDEX command could
have received incorrect index entries. If you suspect this may have
happened, the most reliable solution is to rebuild affected indexes
after installing this update.
судя по всему прямо моя проблема. обновил БД будем посмотреть
> 2017-07-13 10:05 GMT+02:00 Dmitry E. Oboukhov <unera@debian.org>:
> короче рестартанул вчера БД.
> после этого уходить запросы в waiting перестали.
> запустил ANALYZE VERBOSE table - прошло
> запустил для теста VACUUM ANALYZE VERBOSE table;
> дошло до конца: проверило все индексы, обычно такой VACUUM перед
> завершением выдает такие строчки (это с другой таблицы):
> CPU 0.00s/0.00u sec elapsed 0.00 sec.
> INFO: analyzing "public.drivers"
> INFO: "drivers": scanned 15000 of 113723 pages, containing 17459 live
> rows and 56560 dead rows; 15000 rows in sample, 503542 estimated total
> rows
> VACUUM
> про CPU выдало и далее зависло похоже опять навсегда.
> что можно посмотреть?
> --
> . ''`. Dmitry E. Oboukhov <unera@debian.org>
> : :’ :
> `. `~’ GPG key: 4096R/08EEA756 2014-08-30
> `- 71ED ACFC 6801 0DD9 1AD1 9B86 8D1F 969A 08EE A756
> --
> Regards, Andrei Lizenko
--
. ''`. Dmitry E. Oboukhov <unera@debian.org>
: :’ :
`. `~’ GPG key: 4096R/08EEA756 2014-08-30
`- 71ED ACFC 6801 0DD9 1AD1 9B86 8D1F 969A 08EE A756