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 1rPEKE-00A8gN-Am for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Jan 2024 04:11:50 +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 1rPEKC-00DNQc-PS for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Jan 2024 04:11:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rPEKC-00DNQU-Ga for pgsql-hackers@lists.postgresql.org; Mon, 15 Jan 2024 04:11:48 +0000 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rPEK9-001rVs-Me for pgsql-hackers@lists.postgresql.org; Mon, 15 Jan 2024 04:11:47 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 99A7C3200A68; Sun, 14 Jan 2024 23:11:42 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sun, 14 Jan 2024 23:11:43 -0500 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=fm2; t=1705291902; x=1705378302; bh=HfUx+pLFf/ QuuZ6zCY7cjCLDfOH5qIIyXhtNsE/iMbo=; b=B9SggAM4cAN0bulmA6fH8eLTTG DcMsM46krh8iBfPIK2jfsMMRLF6WOE4GKNmwDFufesyUtkUd+dDX+NUEQKJGjJNb KPyX734AnlwLunvDri0RcAVZTTUADd+/sRt+0NeZJtjApuxZ/MOQPF62yCyMR2q0 LEis9xTJ4NBjek/7ocO3IjLF0xL4Uauj2Hy4dlb1p7rdZggnSK4qXcs/lsM/jLXx UMcXXByd9AHGjyPH953/q7q8EuPQ1T+dmQzMxa22bNwqlfw1O7RnFmbRFFgX9z/n IvAEBmHBUI4mIccBMVcYnglopwDItPmuLONzB57BNRR/2nH/I7gotW8I+1EA== 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= fm2; t=1705291902; x=1705378302; bh=HfUx+pLFf/QuuZ6zCY7cjCLDfOH5 qIIyXhtNsE/iMbo=; b=7C78e/6YdDZvQN60xJPpAxGfVLJnLzTlDqUxrrsiG2aq X7u5QqqsPBNMDZAdDbo64GxxgqPfWbePVKvhA2dCpxAcUQlO4k9iUkWAI/Wib5C9 dSjDGUZ8T3ZsY4/A0ONduRqXokXlzbF7TtCZJAM0WYyZ4kr+s1V2iVt258QaLO3E s1SHjKl4s4X5X0dxFt/TGFtqFw4pVCvA2ua0mjL/XpQ6sPM9gaeZL4MApAwlZdjL 6IxwTxhCdpCE/z9BEe2gR7Fg222Dxc8aPKNEt/FWQrTTcPKFL8XriWVJEyDqzDVe X2VJd9y8i5kIiFtnzt6oOpOheMq+WYt0DKQJ2SjfYA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejtddgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne gfrhhlucfvnfffucdljedtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredt tddvnecuhfhrohhmpefoihgthhgrvghlucfrrghquhhivghruceomhhitghhrggvlhesph grqhhuihgvrhdrgiihiieqnecuggftrfgrthhtvghrnhepteelieefudffhffhtdetleeg geegfffhkeeuveetiefgudduvedutefggeeivdejnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepmhhitghhrggvlhesphgrqhhuihgvrhdrgiih ii X-ME-Proxy: Feedback-ID: i0fe9450f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 14 Jan 2024 23:11:39 -0500 (EST) Date: Mon, 15 Jan 2024 13:11:26 +0900 From: Michael Paquier To: Tom Lane Cc: Bertrand Drouvot , Alexander Lakhin , "Yu Shi (Fujitsu)" , Robert Haas , Andres Freund , Thomas Munro , PostgreSQL Hackers Subject: Re: Test slots invalidations in 035_standby_logical_decoding.pl only if dead rows are removed Message-ID: References: <5d0e5bec-67f9-9164-36cb-c4ff5f95d1ed@gmail.com> <6f85667e-5754-5d35-dbf1-c83fe08c1e48@gmail.com> <1375923.1705291719@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bXnikHp6yLVRN+vH" Content-Disposition: inline In-Reply-To: <1375923.1705291719@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --bXnikHp6yLVRN+vH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 14, 2024 at 11:08:39PM -0500, Tom Lane wrote: > Michael Paquier writes: >> While thinking about that, a second idea came into my mind: a >> superuser-settable developer GUC to disable such WAL records to be >> generated within certain areas of the test. This requires a small >> implementation, but nothing really huge, while being portable >> everywhere. And it is not the first time I've been annoyed with these >> records when wanting a predictible set of WAL records for some test >> case. >=20 > Hmm ... I see what you are after, but to what extent would this mean > that what we are testing is not our real-world behavior? Don't think so. We don't care much about these records when it comes to checking slot invalidation scenarios with a predictible XID horizon, AFAIK. -- Michael --bXnikHp6yLVRN+vH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmWksG4ACgkQnvQgOdby QH0woQ//ZKeuFWu0UAkmWsi60AxfAMocAkPp24KCkmj12Grb/RCfX6T4tZuhw6Hx 923Kg8Y96WYWjPKlexCOST3ceDjXXDmds6H60tQo2OblN7wWgKMmlCunALgIxXGI n/C6ZfKLUPgFbn2pchmUmMEObWRCprmucQYpkmox6/UeSAZ+r9STriT/AE1xNz9w 6WoJBbHYJXn9cytXDFBVMOrw8julclKxhVWM3aiEKzMPG2kdazTy/p6Y+6usn6eT Xb/NFL2JSBNqH5qBtbSY1mZjTWblfrGVymwRMEoOU6jxZYQ/SEym3DZ79ZI76CC8 RebEc6l5IcvWWwdHerXMYRSplmgfeHESNuOcrYxgLFXKo4G4qj/uC6hrzK2Re7mj Z07gTUNxvnljo1xlgu5qsWBm323B4TNqcyZru7z5U62BjMKs6DcNq2U5pKYWceWG 7SH0IC04BXC4H2ucBMOQTkckvvTTGjwZHDu7wOrkeDC2urNQJsVG9KscWtrhABlg DlfdfbeoSXy/VdZ9WOHXI77b/y4bUtsgta1Oh8tQ46GElEwqomNLAHBaFdyRcKIG Ks4+z1jxDn1kABuzlxFNex23y0i+RrmfNYRkCbmL7fHwjaPk86Dmcy14IzIk1r49 EMtfPc11VnfzsddjbwMm3+89Dd4a+mHGImPmz3U0PWLT6Mr3L3E= =D3+s -----END PGP SIGNATURE----- --bXnikHp6yLVRN+vH--