Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eA5CP-0008Lz-Sr for pgsql-admin@arkaria.postgresql.org; Thu, 02 Nov 2017 02:25:41 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1eA5CP-0004Wl-88 for pgsql-admin@arkaria.postgresql.org; Thu, 02 Nov 2017 02:25:41 +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 1eA5Ab-00010T-3D for pgsql-admin@postgresql.org; Thu, 02 Nov 2017 02:23:49 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eA5AT-0002V4-Sm for pgsql-admin@postgresql.org; Thu, 02 Nov 2017 02:23:48 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id vA22NbSm019337; Wed, 1 Nov 2017 22:23:38 -0400 From: Tom Lane To: Arjun Ranade cc: pgsql-admin@postgresql.org Subject: Re: Missing Chunk Error when doing a VACUUM FULL operation - DB Corruption? In-reply-to: References: <13631.1509479942@sss.pgh.pa.us> <23996.1509486974@sss.pgh.pa.us> <29089.1509487959@sss.pgh.pa.us> Comments: In-reply-to Arjun Ranade message dated "Wed, 01 Nov 2017 21:49:20 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19335.1509589417.1@sss.pgh.pa.us> Date: Wed, 01 Nov 2017 22:23:37 -0400 Message-ID: <19336.1509589417@sss.pgh.pa.us> List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org Arjun Ranade writes: > So we had a maintenance window scheduled today and I restarted the DB. > When it came back up, it reported the same toast error when vacuum'ing > pg_statistic. It also reported the "oldest xmin is far in the past" error. > I even brought the DB into single user mode and tried to manually vacuum > pg_statistic but got the same error. I also tried to TRUNCATE pg_statistic > in single user mode which failed (see below). > At this point, I am not sure what to make of the issue. The DB is still > complaining about old XMIN even when there are no users connected to it > after a fresh restart: Clearly, something is holding back the xmin horizon, and if the behavior persisted past a DB restart then it surely isn't a regular transaction. Are you *really* sure there are no prepared transactions? It now occurs to me that there's one other mechanism that could hold back the xmin horizon, and that is replication slots. Looking into the pg_replication_slots view should show you what's up there. I'm not an expert on replication slots, but I do know that they were new as of 9.4. I am thinking maybe your replication setup has "leaked" a slot that's not being used but is still preventing global xmin from advancing. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin