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