После того как экстренно (по определенным обстоятельствам) был остановлен, а затем заново запущен postgresql, в логах стали появляться подобные сообщения:
autovacuum: found orphan temp table "pg_temp_xx"."ttxx" in database "xxx".
Postgresql версии 9.1, количество баз 10, количество одновременных пользователей около 100.
В результате "гугления" была найдена следующая информация - можно сделать так:
DROP SCHEMA pg_temp_xxx CASCADE
но по вышеуказанным причинам у меня схем (которые xxx) около 100 и примерно половина из них сейчас явно используются.... поэтому вручную грохать их как то не с руки.
После дальнейшего "гугления" был обнаружен следующий код в исходнике autovacuum.c:
/*
* We found an orphan temp table (which was probably left behind by a crashed backend). If it's so old as to need vacuum for wraparound, forcibly drop it. Otherwise just log a complaint.
*/
if (wraparound)
{
ereport(LOG, (errmsg("autovacuum: dropping orphan temp table \"%s\".\"%s\" in database \"%s\"",
****некий код****
}
else
{
ereport(LOG, (errmsg("autovacuum: found orphan temp table \"%s\".\"%s\" in database \"%s\"",
****некий код****
}
Что говорит о следующем (дословно): после полного оборота autovacuum грохнет эти таблицы сам, но когда он пройдет этот оборот..... уже второй день, а в лог все еще без перерыва сыплются эти сообщения, в результате лог набегает на 200м в день, да и столько ошибок это явно совсем не хорошо.....
Вопрос: как ускорить этот полный оборот autovacuum и как без потерь разрешить данную ситуацию (извиняюсь за многоинформации)
А если попробовать выполнить
А если попробовать выполнить вручную VACUUM FULL на имеющиеся таблицы?
Vacuum Full
выполнил Vacuum Full на базы данных в которых autovacuum находил такие таблицы - не помогло
Ну тогда всё что остаётся,
Ну тогда всё что остаётся, написать маленький скрипт на perl'е или ещё на чём, который распарсит логи, вытащив оттуда имена таблиц и сделает на них DROP.
распарсить...
Спасибо, но пока ищу более элегантное решение. Поиск продолжается, идеи принимаются.....
У меня с базой 1С такая же
У меня с базой 1С такая же ошибка в логах. Удалось как-нибудь решить проблему?