Re: Re: Vaccuuming every db in cluster fails to eliminate "execute a full-database VACUUM in..."
В списке pgsql-admin по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Re: Vaccuuming every db in cluster fails to eliminate "execute a full-database VACUUM in..." |
| Дата | |
| Msg-id | 12329.1286725954@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Vaccuuming every db in cluster fails to eliminate "execute a full-database VACUUM in..." (Robert Burgholzer <rburghol@vt.edu>) |
| Ответы |
Re: Re: Vaccuuming every db in cluster fails to eliminate
"execute a full-database VACUUM in..."
|
| Список | pgsql-admin |
Robert Burgholzer <rburghol@vt.edu> writes:
> So, as I mentioned, I have tried to get this straightened out by
> vacuuming all in --single mode, but to no avail. I executed the
> following command, to see which tables were in trouble:
> SELECT relname, age(relfrozenxid) FROM pg_class WHERE relkind = 'r';
> And found a table listed, that DOES NOT exist any longer.
Yeah? What happens if you try to select from that table?
If there is a row in pg_class that for some reason didn't get deleted
when the table was dropped, you could just manually remove that row
(ie, DELETE FROM pg_class WHERE ... as superuser). You'd still need
another VACUUM to get the database's datfrozenxid updated, but
after that things should be OK.
regards, tom lane
В списке pgsql-admin по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера