Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 6AAED1337B5C for ; Sat, 22 Jan 2011 05:27:44 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 90295-09 for ; Sat, 22 Jan 2011 09:27:37 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.kickstone.com (smtp.kickstone.co.uk [87.194.183.70]) by mail.postgresql.org (Postfix) with ESMTP id 155C71337B47 for ; Sat, 22 Jan 2011 05:27:37 -0400 (AST) Received: from 79-75-75-29.dynamic.dsl.as9105.com ([79.75.75.29]:52130 helo=[192.168.6.15]) by mail.kickstone.com with esmtpa (Exim 4.71) (envelope-from ) id 1PgZkq-0002mE-RJ; Sat, 22 Jan 2011 09:27:32 +0000 Message-ID: <4D3AA304.7070506@kickstone.com> Date: Sat, 22 Jan 2011 09:27:32 +0000 From: John Lister User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Tom Lane CC: John Lister , pgsql-admin@postgresql.org Subject: Re: Should autovacuum do a database wide vacuum near transaction limit? References: <927BF3A3F54247FF8C63219A00CE98B5@squarepi.com> <1427.1295651046@sss.pgh.pa.us> <2081.1295653238@sss.pgh.pa.us> In-Reply-To: <2081.1295653238@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201101/146 X-Sequence-Number: 36586 On 21/01/2011 23:40, Tom Lane wrote: > "John Lister" writes: >> On another bizarre note, A database wide vacuum has just finished, but I'm >> still getting the warnings: >> GMT WARNING: database "backend" must be vacuumed within 10205310 >> transactions > Did you do that vacuum as a superuser? Thanks for your help, but I managed to work it out using an answer you gave in another thread. I looked at which tables had a frozen xid equal to the database value and found that there were 7 temporary tables with numbers equal or very close to it. I couldn't find a way to determine which process created those tables ( - is this possible?) and therefore see how long it had been running, etc Instead I tried to vacuum them, but this didn't make any difference (or indeed do anything), so in the end I deleted the tables manually instead, which instantly reset the transaction count back to the 1billion mark. I now need to find out which process probably died due to its temp tables disappearing, again they appeared odd - single alphabetical names - which I wasn't expecting... Was this expected behaviour with temporary tables? Cheers John