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.94.2) (envelope-from ) id 1r883Z-008Mz5-No for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Nov 2023 00:03:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1r883Y-00807p-8M for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Nov 2023 00:03:56 +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.94.2) (envelope-from ) id 1r883X-00807g-2i for pgsql-hackers@lists.postgresql.org; Wed, 29 Nov 2023 00:03:55 +0000 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r883U-007qXr-Az for pgsql-hackers@postgresql.org; Wed, 29 Nov 2023 00:03:53 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id 29FE85C02E7; Tue, 28 Nov 2023 19:03:51 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 28 Nov 2023 19:03:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1701216231; x=1701302631; bh=8d I5qI4SrCGPBdT/t/yvgcydTvdDMzv9wajoh876S3M=; b=CP16r9juHjPUKRUKms 0e1XVcd07a7ISvJKWe5JNJPwd0wWIB9JSL5GVZNK4XTmzwuyeSdZvFn7C21EvJfu k5FW31MHCqV1fETPOE5zaZPkyFLYlYjmvTmWPOJMoWyxhJLW/pO7Noi5G/ypctsP UxyNllF1LcIbs9Mx7/VGKqxPyOwOSkcswx4juhUjxJCrRY41MjS82SxjXS7p483P qa7L0z97ZSqA5rw2y1WQ7GbMfCCk+6ArTZ7o5iI9xOwNk1kmoxBeqvvQq+gLphu5 7j+s2Sdomkz2pxa2zKVcYmjmlYj47yvQOVUhvtvy/9y/947fYDeqJJMn99NvH3aj vMug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc: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:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1701216231; x=1701302631; bh=8dI5qI4SrCGPB dT/t/yvgcydTvdDMzv9wajoh876S3M=; b=DCazfqPgSWsprbtR6WHZyX1/ZXWYj iMuQBJRq7gl/nQAPXo26NAGPVJqKnz7d7TpsyOtYZcQ0MA+DRQMYEStJff7Bimwg SjqEl96Y+hS5Beocfcv9URrQTTEzf+zVpedChL1VksOceLKermTwv8flANTFzUel hqZVklWXFErHG2mavjMMa+OhYXcMOWCCmiRoPwBXTFuizsKSHYQub3gkuPiBaBgq wiD6gp7y8ViU+HJcdSPAhpzD+2BZ9Vo54KW++NcWzbar1vD463uumXdjBjwMnDct WR+y+NYO2qrMDTx8sUPT/eWzzqllIyNxzXdv75awmX3kWBkKZ/CMz8lmQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeigedgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomheptehnughr vghsucfhrhgvuhhnugcuoegrnhgurhgvshesrghnrghrrgiivghlrdguvgeqnecuggftrf grthhtvghrnhepvdfffeevhfetveffgeeiteefhfdtvdffjeevhfeuteegleduheetvedu ieettddunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh eprghnughrvghssegrnhgrrhgriigvlhdruggv X-ME-Proxy: Feedback-ID: id4a34324:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 28 Nov 2023 19:03:50 -0500 (EST) Date: Tue, 28 Nov 2023 16:03:49 -0800 From: Andres Freund To: Nathan Bossart Cc: David Geier , PostgreSQL-development Subject: Re: Fix assertion in autovacuum worker Message-ID: <20231129000349.pcfvrewvqk4he6i2@awork3.anarazel.de> References: <20231128220516.GA475168@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231128220516.GA475168@nathanxps13> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2023-11-28 16:05:16 -0600, Nathan Bossart wrote: > On Tue, Nov 28, 2023 at 07:00:16PM +0100, David Geier wrote: > > PostgreSQL hit the following assertion during error cleanup, after being OOM > > in dsa_allocate0(): > > > > void dshash_detach(dshash_table *hash_table) { > > ASSERT_NO_PARTITION_LOCKS_HELD_BY_ME(hash_table); > > > > called from pgstat_shutdown_hook(), called from shmem_exit(), called from > > proc_exit(), called from the exception handler. > > Nice find. +1 > > AutoVacWorkerMain() pgstat_report_autovac() pgstat_get_entry_ref_locked() > > pgstat_get_entry_ref() dshash_find_or_insert() resize() resize() locks all > > partitions so the hash table can safely be resized. Then it calls > > dsa_allocate0(). If dsa_allocate0() fails to allocate, it errors out. The > > exception handler calls proc_exit() which normally calls LWLockReleaseAll() > > via AbortTransaction() but only if there's an active transaction. However, > > pgstat_report_autovac() runs before a transaction got started and hence > > LWLockReleaseAll() doesn't run before pgstat_shutdown_hook() is called. > > From a glance, it looks to me like the problem is that pgstat_shutdown_hook > is registered as a before_shmem_exit callback, while ProcKill is registered > as an on_shmem_exit callback. That's required, as pgstat_shutdown_hook() needs to acquire lwlocks, which you can't after ProcKill(). It's also not unique to pgstat, several other before_shmem_exit() callbacks acquire lwlocks (e.g. AtProcExit_Twophase(), ParallelWorkerShutdown(), do_pg_abort_backup(), the first three uses of before_shmem_exit when git grepping) - which makes sense, they are presumably before_shmem_exit() because they need to manage shared state, which often needs locks. In normal backends this is fine-ish, because ShutdownPostgres() is registered very late (and thus is called early in the shutdown sequence), and the AbortOutOfAnyTransaction() contained therein indirectly calls LWLockReleaseAll() and very little happens outside of the transaction context. > I would expect your patch to fix this particular issue, but I'm wondering > whether there's a bigger problem here. Yes, there is - our subsystem initialization, shutdown, error recovery infrastructure is a mess. We've interwoven transaction handling far too tightly with error handling, the order of subystem initialization is basically random and differs between operating systems (due to EXEC_BACKEND) and "mode" of execution (the order differs when using single user mode) and we've distributed error recovery into ~10 places (all the sigsetjmp()s in backend code, xact.c and and a few other places like WalSndErrorCleanup()). Greetings, Andres Freund