Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1edZQk-0005aM-7J for pgsql-performance@arkaria.postgresql.org; Mon, 22 Jan 2018 10:34:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1edZQj-0006PZ-M8 for pgsql-performance@arkaria.postgresql.org; Mon, 22 Jan 2018 10:34:21 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1edZEY-0005EM-VO for pgsql-performance@lists.postgresql.org; Mon, 22 Jan 2018 10:21:47 +0000 Received: from n3.nabble.com ([162.255.23.22]) by magus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1edZET-0007Af-TF for pgsql-performance@postgresql.org; Mon, 22 Jan 2018 10:21:44 +0000 Received: from n3.nabble.com (localhost [127.0.0.1]) by n3.nabble.com (Postfix) with ESMTP id 869BBAC546CB for ; Mon, 22 Jan 2018 03:21:39 -0700 (MST) Date: Mon, 22 Jan 2018 03:21:39 -0700 (MST) From: pavan95 To: pgsql-performance@postgresql.org Message-ID: <1516616499481-0.post@n3.nabble.com> In-Reply-To: <987851516614060@web46o.yandex.ru> References: <46D83427.60001@livedatagroup.com> <1516601350338-0.post@n3.nabble.com> <987851516614060@web46o.yandex.ru> Subject: Re: 8.2 Autovacuum BUG ? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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