Re: Recovering a database in danger of transaction wrap-around
В списке pgsql-admin по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Recovering a database in danger of transaction wrap-around |
| Дата | |
| Msg-id | 19119.1201295646@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Recovering a database in danger of transaction wrap-around (Steven Rosenstein <srosenst@us.ibm.com>) |
| Ответы |
Re: Recovering a database in danger of transaction wrap-around
|
| Список | pgsql-admin |
Steven Rosenstein <srosenst@us.ibm.com> writes:
> I used plain old VACUUM. Do you think VACUUM FULL might be faster or more
> effective?
No. I think you probably want to do a dump and reload, but first you
have to get past the anti-wraparound check.
One possibility I hadn't thought of before is to use a standalone
backend to increment the pg_database.datfrozenxid values by a few
thousand transactions. This would be a bad idea if you intended
to keep using the DB, but if you're just trying to get to a state
where you can run pg_dump, it seems acceptable.
regards, tom lane
В списке pgsql-admin по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера