Hello Sergi, The size of the database is 24GB. The output of the above query is : datid | datname | procpid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | xact_start | query_start | waiting | current_query --------+----------+---------+----------+----------+------------------+-------------+-----------------+-------------+----------------------------------+----------------------------------+----------------------------------+---------+-------------------------------------- 400091 | prod_erp | 19373 | 10 | postgres | | | | | 2018-01-22 15:40:38.163865+05:30 | 2018-01-22 15:40:38.655754+05:30 | 2018-01-22 15:40:38.655754+05:30 | f | autovacuum: ANALYZE public.table1 400091 | prod_erp | 19373 | 10 | postgres | | | | | 2018-01-22 15:40:38.163865+05:30 | 2018-01-22 15:40:38.655754+05:30 | 2018-01-22 15:40:38.655754+05:30 | f | autovacuum: ANALYZE public.table1 400091 | prod_erp | 19373 | 10 | postgres | | | | | 2018-01-22 15:40:38.163865+05:30 | 2018-01-22 15:40:38.218954+05:30 | 2018-01-22 15:40:38.218954+05:30 | f | autovacuum: ANALYZE public.table2 400091 | prod_erp | 18440 | 10 | postgres | | | | | 2018-01-22 15:39:38.128879+05:30 | 2018-01-22 15:39:38.166507+05:30 | 2018-01-22 15:39:38.166507+05:30 | f | autovacuum: VACUUM public.table3 Could you please explain what antiwraparound autovacuum is?? Is it related for preventing transactionID wraparound failures? If so does running vacuum full against the database will suppress this abnormal generation of archive logs?? Please give your kind advice. Regards, Pavan -- Sent from: http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html
