Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1heJwn-0001NL-KJ for pgsql-admin@arkaria.postgresql.org; Fri, 21 Jun 2019 13:51:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1heJwm-0003vH-7A for pgsql-admin@arkaria.postgresql.org; Fri, 21 Jun 2019 13:51:20 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1heJwk-0003us-6D for pgsql-admin@lists.postgresql.org; Fri, 21 Jun 2019 13:51:19 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1heJwg-0000rj-HZ for pgsql-admin@postgresql.org; Fri, 21 Jun 2019 13:51:17 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5B38D22233; Fri, 21 Jun 2019 09:51:11 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Fri, 21 Jun 2019 09:51:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= quadratum-braccas.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=6vtD 5wwSgUz9Ffm7UGSzOKSKLaRgjfJH/z1K06F6HBc=; b=cuNZzXjCskahUmHH8MeW +YbhtZpftQsr8RaRYO+TnR/bTe2prTHj6gHrajmdXXwJxNP7Gl7OUpbT2b5nQ5EW cA7VKTDAbBJJ+0ttUXnVe03ITF7UAOCE3F9fFyIuFfZQntxZflUfvbQmtsrCS/p3 iUoTEsciWM7iO8bHe55rz0nhOHiELtCA00v3ZSRaw9lgHdlvMo2QZjeY18DhhD3L vTvzeIOLEWKAbBPs73L7Y0XwDf4xYGoks84QwES6tf6x4IIFomt8LdHtGH9IUz4g +sIAzoep3LbEsF54dv+qEbSn3fHEHoqNNfbznlxJzDl9fFA3NPCtceqTFjvAA9pL Ww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=6vtD5w wSgUz9Ffm7UGSzOKSKLaRgjfJH/z1K06F6HBc=; b=T36vPKBL+TsCoelQlsPJJR CQ1s7WZjGZJm2k7AuZ1b7xCIRxqoGkD1cqWk38alwoN59tE4HYI9vUPdCvrWRYIe 6p3rtmEFJQM4BaDWAPpR2wGCJX9yOWXNK17cg0FRLOFfUQEDgmy86czTR1xK24Zc PEHH6HtDa5ob/wYfZ94T4sDFAJkEVBSYAqzDrbCU2XE1Jz8QVRREOee6RmGbgBKX utKPNV6ziYP6RlhEQK7qhJ3AUvR+x6ea9CrFKF2wBkhf4H/5ntxMUT4BFKrBknYM S65UHlQDyVU3SiWkaBKxiG8XPmrw99LY1BEBaT/9fO7kCKsQwQJEgGbMr7zVdaRQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrtdeigdejvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepufeuohgsuceoshgsohgssehquhgrughrrghtuhhmqdgsrhgr tggtrghsrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomhepshgsohgssehquhgrug hrrghtuhhmqdgsrhgrtggtrghsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 473F9C200A3; Fri, 21 Jun 2019 09:51:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-728-g133121a-fmstable-20190620v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <02C3BE5C-ED36-4B36-85C3-90C774FA528B@crazybean.net> References: <15eddc60-6441-e55e-f742-bd7ea37f1873@quadratum-braccas.com> <31037.1560988222@sss.pgh.pa.us> <053c95f2-1425-23ac-0308-ca22887db156@quadratum-braccas.com> <02C3BE5C-ED36-4B36-85C3-90C774FA528B@crazybean.net> Date: Fri, 21 Jun 2019 09:51:09 -0400 From: SBob To: "Rui DeSousa" , Keith Cc: "Tom Lane" , pgsql-admin Subject: Re: Vacuum not cleaning up rows. Content-Type: multipart/alternative; boundary=75560756f3b8443f8713ee02e4b48d32 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --75560756f3b8443f8713ee02e4b48d32 Content-Type: text/plain I do see older backend_start values (from around 6 hours ago). However I am confused as to how a connection to one database in a cluster can prevenr vacuum from cleaning up row versions in a table within another database. How is that possible since onle one database has access to this table? On Thu, Jun 20, 2019, at 2:37 PM, Rui DeSousa wrote: > > In addition to what others have already stated to check; also check for replication slots. > > > select * from pg_replication_slots; > > --75560756f3b8443f8713ee02e4b48d32 Content-Type: text/html
I do see older backend_start values (from around 6 hours ago). However I am confused as to how a connection to one database in a cluster can prevenr vacuum from cleaning up row versions in a table within another database.   How is that possible since onle one database has access to this table?



On Thu, Jun 20, 2019, at 2:37 PM, Rui DeSousa wrote:

In addition to what others have already stated to check; also check for replication slots.


select * from pg_replication_slots;


--75560756f3b8443f8713ee02e4b48d32--