Re: BUG #16620: Autovacuum does not process certain databases after migration from postgresql 10
От | Tom Lane |
---|---|
Тема | Re: BUG #16620: Autovacuum does not process certain databases after migration from postgresql 10 |
Дата | |
Msg-id | 98503.1600305594@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #16620: Autovacuum does not process certain databases after migration from postgresql 10 (Max Vikharev <bm.kinder@gmail.com>) |
Ответы |
Re: BUG #16620: Autovacuum does not process certain databases after migration from postgresql 10
|
Список | pgsql-bugs |
Max Vikharev <bm.kinder@gmail.com> writes: > Problem gone after restarting the cluster. > Autovacuum started to process relations in other databases. Hmm, interesting. > I dont know how to reproduce the issue, we will monitor it. > If there any way to debug it when it occurs again - let me know. Did you by any chance capture the contents of pg_database.datfrozenxid and datminmxid and compare them to the pg_class.relfrozenxid and relminmxid fields in the problematic databases? It's not hard to imagine that if the pg_database fields somehow didn't get updated correctly during pg_upgrade, that would prevent autovacuum from processing some databases to prevent wraparound. However, that doesn't explain failure to examine those databases at all, so I'm a bit at a loss. Another thing to check is whether the stats collector is working. Specifically look at whether counts in pg_stat_all_tables are incrementing in the problem databases. My guess is that somehow pg_upgrade left something in a slightly hosed state, and that restarting de-hosed it, so that you aren't going to see this again ... at least not till your next upgrade. But I don't know exactly what the something could be. regards, tom lane
В списке pgsql-bugs по дате отправления: