Сообщение в логе postgresql - autovacuum: found orphan temp table in database

После того как экстренно (по определенным обстоятельствам) был остановлен, а затем заново запущен 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 (официальный код postgresql):
/*
* 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 и как без потерь разрешить данную ситуацию (извиняюсь за многоинформации)

0

Небось это 1С так мусорит? (без обид).
Не надо дропать всю схему, дропните таблицу (грепом выбрать из логов имена схема, имена таблиц...)
скорее всего эти таблицы были созданы через CREATE TEMPORARY TABLE для построения каких-то временных отчетов и они врядли жестко связаны с основной схемой данных. То есть вы с большой веростяностью ничего не порушите.
Если я угадал и это 1С, то дело серьезное. И все же лучше не надеяться на вероятность и перед дропом дождаться (или сделать вручную, если не настроено автоматически) полного бакапа данных (ночного?!).

Также должно помочь VACUUM FULL, хотя я не попадал в такую ситуацию и не знаю, удалит ли сборщик мусора "осиротвешие" таблицы. Но VACUUM FULL требует эксклюзивного доступа к таблицам. Соответственно полную вакуумизацию нужно делать, когда никто не работает.

0

Естественно 1С, и извиняться тут не за что :- ))))) 1С действительно д-мо но без него далеко не убежишь.... А теперь по делу, grep-ом не вариант как я говорил их больше 50.... отобрать их все не так уж и легко, да и мне бы хотелось, чтобы postgres их сам грохнул - что судя по найденной мною информации заложено в программу, а не я вручную во избежании еще худших последствий чем сейчас....
За vacuum full спасибо ;-) но не помогло :-(

0

можно попытаться уменьшить параметр freeze_max_age, это уменьшит время до wraparound'а и соответственно, когда он случится, выполнится условие, о котором вы написали выше и таблицы должны дропнуться при автовакуумизации.

0

Да, спасибо, где-то видел про это информацию, наверное в докумментации postgresql - здесь
23.1.3. Preventing Transaction ID Wraparound Failures
только там есть еще указание:
WARNING: database "mydb" must be vacuumed within 177009986 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in "mydb".

If these warnings are ignored, the system will shut down and refuse to execute any new transactions once there are fewer than 1 million transactions left until wraparound:

ERROR: database is not accepting commands to avoid wraparound data loss in database "mydb"
HINT: Stop the postmaster and use a standalone backend to VACUUM in "mydb".

к сожалению не смог однозначно понять что бы это значило, поэтому боюсь что то предпринимать в этом направлении, ибо если postmaster встанет - это в моей ситуации каснется всех 10 баз, деятельность фирмы тоже нагнется :-))) а потом скорее всего нагнусь я :-(
grgdvo - не подскажете, есть ли тут чего опасаться?
я попробовал бы на тестовом сервере но пока не удалось смоделировать ситуацию

0

За простую вакуумизацию я бы не опасался.
Тем более, что это в приницпе полезная вещь и она должна делаться наряду с бакапами.

But since transaction IDs have limited size (32 bits) a cluster that runs for a long time (more than 4 billion transactions) would suffer transaction ID wraparound: the XID counter wraps around to zero, and all of a sudden transactions that were in the past appear to be in the future — which means their output become invisible. In short, catastrophic data loss. (Actually the data is still there, but that's cold comfort if you cannot get at it.) To avoid this, it is necessary to vacuum every table in every database at least once every two billion transactions.

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

Там же в разделе приведены запросы, посмотрите на ваши счетчики транзакий, засеките с какой скоростью они растут. Если Вам хватит счетчиков еще на 100 лет вперед, то играться с параметрами возраста думаю бессмысленно, проще взять и дропнуть "осиротевшие" таблицы... ну или мириться с мусором в логах.

0