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 1sGYf6-00ETFf-8a for pgsql-bugs@arkaria.postgresql.org; Mon, 10 Jun 2024 06:37:49 +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 1sGYf4-008Nq2-Bn for pgsql-bugs@arkaria.postgresql.org; Mon, 10 Jun 2024 06:37:47 +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 1sGYf3-008Npt-V1 for pgsql-bugs@lists.postgresql.org; Mon, 10 Jun 2024 06:37:46 +0000 Received: from fhigh4-smtp.messagingengine.com ([103.168.172.155]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sGYf2-000aIc-5M for pgsql-bugs@lists.postgresql.org; Mon, 10 Jun 2024 06:37:45 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfhigh.nyi.internal (Postfix) with ESMTP id E35661140193; Mon, 10 Jun 2024 02:37:42 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 10 Jun 2024 02:37:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1718001462; x=1718087862; bh=iC3KmL7SyJ uPKLQzeYqiRgTMfmrI/vu4M/mHBsKmg9A=; b=WERSvZQoK7Rsn7ELoDPdjNpTQ8 2zhvVY2v7btjWOgufwqS7XhblOvgYNFO6NjcBdAYuZEF6cet+HsfnW4J3Nf9WnUO sevHgQnMDa6YvTVyUvzrZExt/6+q2KmkaQszWDa9vAopypfaUGBzgfDP+SnohEO0 asB5kC4UCa2YiyVtYNTN9KvuwYK4koez6w5hcg6CODzqejdFqY/E1GeTj9P3beKl JQIvIsLI0v2/WCWPPfyC1nKmjVAQYhf0JmkK8H2vXMgWv0Bwtex0SURgGzT5BMoS 9KDGG3dk2AlSdZcOBHJkiUXs6wXGFonZ69eoHwEOdT08i3azmDt0OIsag80Q== 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:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1718001462; x=1718087862; bh=iC3KmL7SyJuPKLQzeYqiRgTMfmrI /vu4M/mHBsKmg9A=; b=d3fZilgd6XwSSYy3Hw+ma1EF4V8MjxeTQFr4rJzt+/qv x2AJLnyUVbIeBNpUMgNxjc88lTuneK+ZYpM/SJIk5xXOyK+NkWbKefOPvuK7UdEh +Llh1In/FO8ShGMA2j6Hpa4oJl5vGHqfaEg5cD8GL1grb2DFHqEUjt2AkED26Ey9 GfJZp/pW/3wq0ykrudVdpsQcg49rlK7jOKquD7JAJsUB9UieXDxY5LpMUOHZFGPq 7kMyAhSRJLku0IkD38gYpnxctyiP29W/W3UMMJAFaDS2V4/00om60iBT8Mvef5g8 BKezbcMiyW4cvJetdITlBDdk0vWDamg1moMkO49+Kg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedtledgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne gfrhhlucfvnfffucdljedtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredt tddvnecuhfhrohhmpefoihgthhgrvghlucfrrghquhhivghruceomhhitghhrggvlhesph grqhhuihgvrhdrgiihiieqnecuggftrfgrthhtvghrnhepteelieefudffhffhtdetleeg geegfffhkeeuveetiefgudduvedutefggeeivdejnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepmhhitghhrggvlhesphgrqhhuihgvrhdrgiih ii X-ME-Proxy: Feedback-ID: i0fe9450f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 10 Jun 2024 02:37:39 -0400 (EDT) Date: Mon, 10 Jun 2024 15:37:24 +0900 From: Michael Paquier To: Floris Van Nee Cc: Bertrand Drouvot , Andres Freund , Kyotaro Horiguchi , "tgl@sss.pgh.pa.us" , "pgsql-bugs@lists.postgresql.org" Subject: Re: error "can only drop stats once" brings down database Message-ID: References: <68430b1b76d44558b7b07ae8c69151f6@Optiver.com> <20240607.101540.1972690976596948719.horikyota.ntt@gmail.com> <20240607031258.l4fcpvulo3uee5g6@awork3.anarazel.de> <2cb577e176774caca28c724898768a38@Optiver.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kfQEn90Oto44/evi" Content-Disposition: inline In-Reply-To: <2cb577e176774caca28c724898768a38@Optiver.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --kfQEn90Oto44/evi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 08, 2024 at 11:52:43AM +0000, Floris Van Nee wrote: > I've got an update about the bug. I managed to reproduce it locally > after a lot of digging. > > How to repro: > - Setup primary + replica > - Open a psql session on both > - On primary session: create table t (a int); select 't'::regclass::oid; > - On replica session: select * from t; > - On primary session: drop table t; vacuum pg_class; checkpoint; > - Gdb attach to the backend for your primary, set a breakpoint for=20 > catalog.c:GetNewOidWithIndex, just before it calls GetNewObjectId() > - On primary session: create table t (a int); > - When it hits breakpoint, simulate oid wraparound by setting: > ShmemVariableCache->nextOid =3D > This will make pg create the new table with the same oid as the previous = one. > - On primary session: drop table t; -- this triggers the replica to go do= wn Okay, this stuff makes the beginning of a week fun. > The reason it crashes on replica is that the recovery process is responsi= ble for dropping > stats on commit, but it's not creating them on table creation. Thus, on t= he second create > table call, the old shared stats entry still exists (due to a backend sti= ll have a ref to it), > but it is never reinitialized by the logic in pgstat_reinit_entry(). On p= rimary it's not possible > to reach this state, because heap_create() creates the stats entry immedi= ately when the > table is created. > > I wonder what's the best way to fix this though. > Should redo process call pgstat_create_relation somewhere, just like heap= _create does? > Should we just ignore this 'drop stats twice' error on standby? Nah, ignoring the double-drop error does not seem right to me. Wouldn't it make the most sense to ensure that the stats are dropped on the standby instead on the first DROP replayed even if there are still references to it hold, making sure that the stats entry with this OID is gone before reusing it after wraparound? -- Michael --kfQEn90Oto44/evi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmZmnyQACgkQnvQgOdby QH2ybw/9GZrbx89xnSfxz2orvnq+DLK0z98d+hL+qq1C5vMMtyUx5WoscYYpIEJ9 yQ2AUUtqAJSE6B0lYjVCAFmRPWEUm7/xoVGeyjobrqbhjk84d9mYN+Bre+KOz0Ci nldme1fXN8WIa34pWYZvl4HqvVqi0TTw0ntlA99uSGBlL8nU6ZMba5R0nBz00cXv WfuHEHbCFiQwN6QJWPYXS3XuLrZd464Y53c85IFOFMwmyp/15rda2Kp/n+0miXYF RDA7fL6NzI7FAe/JbMpMXj2EzrR9wC8WzAXWkj+E1TX940J7RF/g4hy2assZI+ga +zzqnBQdKT3KLOXIQdTF+YcuJ3zcgaDhavP6MCN/synoyHk5o9d/3zyVmk/qvCwf zgpSqWFQlZHyS7bmWxkkJpRFgjqtRvmHhg8GA5p5g2Jrt+AHkm55jbvqUhHcugcn gHTkPashqjvHuGLoTlA6LEYku3SPDVK2t4SysXJaHKR7Q/mgy5DuNgMTHdeR5w7i 4MoTCCczb35/i4MMZNI3q7135L8tPtyC3e5HaugYCr8QRMky3cYUtt06XU6p6MD3 x1AH54BDqXXpvfecdj4JNlH6wkHZKpHrIqZSSf+GJ6Eunlfr9vQgkMd9DrsZA8ao AA8TnertSkow1EMEfTdeqCKfpVWlxcGG4CnKcq/ka6Wu5Z0sp6E= =jR0N -----END PGP SIGNATURE----- --kfQEn90Oto44/evi--