Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vJFeW-00GGOt-0W for pgsql-admin@arkaria.postgresql.org; Wed, 12 Nov 2025 18:33:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vJFeT-00DY1c-22 for pgsql-admin@arkaria.postgresql.org; Wed, 12 Nov 2025 18:33:05 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vJFeT-00DY1T-0s for pgsql-admin@lists.postgresql.org; Wed, 12 Nov 2025 18:33:05 +0000 Received: from fhigh-b4-smtp.messagingengine.com ([202.12.124.155]) by makus.postgresql.org with smtp (Exim 4.96) (envelope-from ) id 1vJFeR-006m5p-1g for pgsql-admin@lists.postgresql.org; Wed, 12 Nov 2025 18:33:04 +0000 Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id 516CC7A0125; Wed, 12 Nov 2025 13:33:02 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Wed, 12 Nov 2025 13:33:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= quadratum-braccas.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to; s=fm2; t=1762972382; x=1763058782; bh=1nViawwNqJoF2 h+feCgz50JNlBuEXUuzLakhuNvbj1I=; b=jBfPG7DHk+08O7X9GyG1VQlGyX1Mr jKHshCI5sfxpMhh/RMk7Cl238ZFh8EzOJbZ977JLGZ2Qumx6X7p50MiVP5QSx8oo WAdp98tDExFBvJ3edUNH2WiFuojxq9fWfn7Cn/hiL/j5gB3aaRVfrDZWD3kMj3vM kRYcb/OJyyicChhIVTy3Bf7NL5OkMLXLqZeNU7kpz5AuOQapSoRulNaX5BncHg64 MiiIx4kYdNAe8GxyUJxgWly1rBf+s2XfJhtbtQFYfIm//EvnSg2ahaSlBZfsDLj8 v0jyAlehyTMDpMqidrYjf+Uvaz829R3NBbo/XSiykF8Jv7zDOzhfma5KA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1762972382; x=1763058782; bh=1 nViawwNqJoF2h+feCgz50JNlBuEXUuzLakhuNvbj1I=; b=Ev2iLzhPp3dzBi+eq e6AugXq2vMvxJaHg5kz6cJj1L6Vs685bOVx0RKBd6yvXN/xhmehk9IIH8UM/SQKx LukzCURBEiOhE6D/b6prMpF0gb0p//1QRXn9qYgVgHjvYQo8iYGlmrkfnhyOhl03 kbuvQZm7tJUasXIo2REx9FK9lIhAsX94nVerfAHjAtfGjTZ7VAOZZL4K2RcZQ2Ul EbLsXCeP0a9xmHhy0/LtGJPw7AfLBJTBfBcm6CLyjKcxmLJqDUpb/OiJva8rGwf8 h6n9A+V3S1BU6SMZ9/WV/Nq/l7g6ROFMXIFPDPw/HgNx3PJb8320m6zs4gfvj54A zRQSg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvtdegkedtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenuchmihhsshhinhhgucfvqfcufhhivghlugculdeftddmne cujfgurhepkfffgggfufevfhfhjggtgfesthekredttddvjeenucfhrhhomhepufgsohgs uceoshgsohgssehquhgrughrrghtuhhmqdgsrhgrtggtrghsrdgtohhmqeenucggtffrrg htthgvrhhnpeehheeltdeffedvffehtefhheeiiefgleelvedvkeetheelvdffhfetveev feffheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hssghosgesqhhurggurhgrthhumhdqsghrrggttggrshdrtghomhdpnhgspghrtghpthht ohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepphhgshhqlhdqrggumhhinh eslhhishhtshdrphhoshhtghhrvghsqhhlrdhorhhgpdhrtghpthhtohepshgsohgssehq uhgrughrrghtuhhmqdgsrhgrtggtrghsrdgtohhm X-ME-Proxy: Feedback-ID: i374947ac:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 12 Nov 2025 13:33:01 -0500 (EST) Message-ID: Date: Wed, 12 Nov 2025 11:33:00 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: vacuum process running for more than 2 days, still in scanning heap phase Cc: pgsql-admin@lists.postgresql.org References: <202511121819.yuoha4w6sprz@alvherre.pgsql> Content-Language: en-US From: Sbob In-Reply-To: <202511121819.yuoha4w6sprz@alvherre.pgsql> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 11/12/25 11:26 AM, Álvaro Herrera wrote: > On 2025-Nov-12, Sbob wrote: > >> We have a vacuum process that has been running for 2 days, the table >> is 12GB in total size and vacuum_cost_delay is at 0 > Is it autovacuum? Because if so, the autovacuum_vacuum_cost_delay > setting would be used instead of this one. Also check the table config > (\d+) in case there are autovacuum settings there, which could make > vacuum slower on this particular table. > > What PG version again? > > This is not autovacuum, we ran a vacuum freeze manyally > > Version 15 >> heap_blks_total    | 571437 >> heap_blks_scanned  | 344577 >> heap_blks_vacuumed | 0 >> index_vacuum_count | 0 >> max_dead_tuples    | 155388267 >> num_dead_tuples    | 199013 > Yeah, this seems really slow. Maybe have a look at the wait events in > pg_stat_activity to see if you can figure out what is holding it back. pg_stat_activity shows no wait events and shows state as active >> We actually tried a pg_terminate_backend on it and it does not die > Hmm, maybe there's something going wrong with it. I've seen corrupted > btree indexes make a vacuum go into infinite loops because of loops in > the index structure. I would take a few backtraces with gdb or such. > Maybe if an index is corrupt in that way, it would also explain why it > doesn't interrupt. I'll give it a shot, thanks