Re: pg_multixact issues
От | Dev Kumkar |
---|---|
Тема | Re: pg_multixact issues |
Дата | |
Msg-id | CALSLE1NT9c9eYs95Q3=7C5dWkzrrULQTy6bcSkFsP1OKA+AXHg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_multixact issues (Adrian Klaver <adrian.klaver@aklaver.com>) |
Ответы |
Re: [GENERAL] pg_multixact issues
|
Список | pgsql-sql |
On Thu, Sep 18, 2014 at 2:41 AM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
Aaah, hit enter too soon. Also see the other changes under Changes that apply to multixact in 9.3.5
Thanks for sharing same. Found this one interesting "Truncate pg_multixact during checkpoints, not during VACUUM (Álvaro Herrera)" and also other changes. But am not sure are you suggesting to move to 9.3.5 ?
Actually looking for some guidelines on truncating pg_multixact at this situation.
- Do I need to run vaccum manually here and then the pg_multixact can be truncated?
- Actually looking out for some hints wherein can know the current pg_multixact/members which are active and which one are stale which can be truncated? Is there any query to find this information?
- Do I need to run vaccum manually here and then the pg_multixact can be truncated?
- Actually looking out for some hints wherein can know the current pg_multixact/members which are active and which one are stale which can be truncated? Is there any query to find this information?
pg_class.relminmxid can be referred but should I change the value of autovacuum_multixact_freeze_max_age which defaults to 400 million multixacts, setting this value to lower limits would help in cleaning up pg_multixact?
Regards...
Regards...
В списке pgsql-sql по дате отправления: