sudo smartctl -H /dev/sda2
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.1.12-124.22.2.el7uek.x86_64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

вот и как понять что с постгрей что то не так, в логах постгри никаких пролем не видно

Здравствуйте, как можно удалить такие временные таблицы? Для них нет схемы...

> сами инстансы постгри вне кубер кластера на vmware виртуалках

у вас тут несколько слоев абстракций, если искать причины/ошибки, то нужно проверять все 1) ос в виртуальной машине, 2) гипервизор 3) оборудование на котором запущен гипервизор, 4) хранилище, если оно внешнее

если задача проверить валидность данных в постгресовом инстансе и затем переключиться на него, то тут разные варианты - самый простой это сделать дамп (см. pg_dump) и рестор (см. pg_restore) из полученного дампа на какой-то отдельной временной машине. Если ошибок в обоих процессах не будет, то с высокой вероятностью с данными все порядке.

в зоне доступности только вмки, в прошлый раз запрашивал логи вм и гипервизора, ниче подозрительного не было- никуда она не переезжала, никак не обслуживалась. могу грешить на саму постгрю

Ну и что? ;)
Вы в логах системы посмотрите, во-первых.
Во-вторых, современные компьютеры, всё же, состоят не только из дисков. ;)
А, и если это виртуалки и т.п. (да и даже если нет), то это могут быть проблемы с "честностью" fsync, да и всё.

> ниче подозрительного не было

это вам ваша тех.поддержка написала? что за провайдер если не секрет?

ну вот задерживает что то запись на диск и fsync не отрабатывает вовремя, почему постгря считает что нужно апдейтить лог транзакций в несуществующем файле. Кстати в прошлый раз она так же ссылалась на 0152

ну вот задерживает что то запись на диск и fsync не отрабатывает вовремя, почему постгря считает что нужно апдейтить лог транзакций в несуществующем файле. Кстати в прошлый раз она так же ссылалась на 0152

просто удаляете. drop table if exists tt37;

Потому что вследствие "fsync не отрабатывает вовремя" в базе уже оказался "мусор", и когда PostgreSQL его потом читает и пытается интерпретировать (а он, к примеру, "означает" что это запись из никогда не существовавшей транзакции), то происходит вот это вот.

> Кстати в прошлый раз она так же ссылалась на 0152

Это оттого, что кто-то не занялся проблемой вовремя, а попытался её "замести под ковёр". ;(

Это временные таблицы, их нет в схеме public...

Это временные таблицы, их нет в схеме public...

нужно было приложить подорожник

> почему постгря считает что нужно апдейтить лог транзакций в несуществующем файле

постгрес считает что файл существует, а то что его не существует по факту - это называет неконсистенстность.
кстати если нерадивыми руками удалить такой или подобный файл из pg_xact, то нигде никаких фактов об удалении не будет зафиксировано, но при этом проблемы из-за это начнутся

пока компетенции по поиску такой проблемы нет

ктсти на реплику не прилетел 0152 файлик который я создал на мастере