Re: AutoVacuum and growing transaction XID's - Mailing list pgsql-general

From github kran
Subject Re: AutoVacuum and growing transaction XID's
Date
Msg-id CACaZr5RQbHW9C_1SDH+FdnJ8cgoj5giN3Fwd7WLGyg+Qth=KXw@mail.gmail.com
Whole thread Raw
In response to Re: AutoVacuum and growing transaction XID's  (Michael Lewis <mlewis@entrata.com>)
Responses Re: AutoVacuum and growing transaction XID's  (github kran <githubkran@gmail.com>)
Re: AutoVacuum and growing transaction XID's  (github kran <githubkran@gmail.com>)
Re: AutoVacuum and growing transaction XID's  (David Rowley <dgrowleyml@gmail.com>)
Re: AutoVacuum and growing transaction XID's  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-general


On Thu, May 7, 2020 at 1:33 PM Michael Lewis <mlewis@entrata.com> wrote:
It is trying to do a vacuum freeze. Do you have autovacuum turned off? Any settings changed from default related to autovacuum?

Read 24.1.5. Preventing Transaction ID Wraparound Failures


Note that you need to ensure the server gets caught up, or you risk being locked out to prevent data corruption.

  Thanks Mike. 
1)  We haven't changed anything related to autovacuum except a work_mem parameter which was increased to 4 GB which I believe is not related to autovacuum 
2)  The vacuum was not turned off and few parameters we had on vacuum are 
                 autovacuum_analyze_scale_factor = 0.02 and autovacuum_vacuum_scale_factor = 0.05
3) The database curently we are running is 2 years old for now and we have around close to 40 partitions and the datfrozenxid on the table is 343 million whereas the default is 200 million.  I would try doing a manual auto vacuum on those tables
where the autovacuum_freeze_max_age > 200 million. Do you think It's a right thing to do ?.

I will also go through this documents. 

Tahnks
 

pgsql-general by date:

Previous
From: Tory M Blue
Date:
Subject: Memory footprint diff between 9.5 and 12
Next
From: Alan Hodgson
Date:
Subject: Re: Memory footprint diff between 9.5 and 12