Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oExzr-0001fN-CA for pgsql-bugs@arkaria.postgresql.org; Fri, 22 Jul 2022 19:07:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oExzp-0001o6-Uk for pgsql-bugs@arkaria.postgresql.org; Fri, 22 Jul 2022 19:07:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oExzp-0001nx-MM for pgsql-bugs@lists.postgresql.org; Fri, 22 Jul 2022 19:07:33 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oExzn-0006ct-B5 for pgsql-bugs@lists.postgresql.org; Fri, 22 Jul 2022 19:07:32 +0000 Received: from bruce by momjian.us with local (Exim 4.94.2) (envelope-from ) id 1oExzl-009NCx-IX; Fri, 22 Jul 2022 15:07:29 -0400 Date: Fri, 22 Jul 2022 15:07:29 -0400 From: Bruce Momjian To: Marco Boeringa Cc: pgsql-bugs@lists.postgresql.org Subject: Re: Fwd: "SELECT COUNT(*) FROM" still causing issues (deadlock) in PostgreSQL 14.3/4? Message-ID: References: <85acb61d-4cbf-7544-c734-429993257547@boeringa.demon.nl> <791d1850-f337-8914-1ba0-512f4e0fef26@boeringa.demon.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <791d1850-f337-8914-1ba0-512f4e0fef26@boeringa.demon.nl> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Jul 22, 2022 at 09:56:06AM +0200, Marco Boeringa wrote: > Unfortunately, after more testing, it turns out this issue still persists in > PostgreSQL 14.4. > > I have now encountered exactly the same problem as described in the original > issue below: One autovacuum session that never finishes with no wait event (or > is just incredibly slow and not finishing after many hours although it should > in minutes considering the relative small dataset and normal operation), and > the "client backend" and "parallel worker" stuck on the same wait events as > listed below  with the same "SELECT COUNT (*)" SQL statement. > > One thing to note as well, besides this being workstation level hardware with > ECC RAM, is that I now also activated 'pg_checksums' on the PostgreSQL > databases, and reloaded all data, so all data should now have checksums.  No > PostgreSQL error at all is generated via the ODBC connection I use to access > and update the database when this happens and PostgreSQL appears stuck on the > autovacuum. So I guess this now means I can now pretty much exclude a hardware > error, and this must be some software issue, considering the checksums. You might want to run these queries and show us the output, in case it suggests a cause: SELECT version(); -- non-default server settings SELECT name, current_setting(name), source FROM pg_settings WHERE source NOT IN ('default', 'override'); -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson