Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g9mpO-0001FJ-Gk for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Oct 2018 07:53:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g9mpL-00056U-Qh for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Oct 2018 07:53:11 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g9mpK-00056F-2E for pgsql-hackers@lists.postgresql.org; Tue, 09 Oct 2018 07:53:11 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g9mpF-0007oc-M9 for pgsql-hackers@lists.postgresql.org; Tue, 09 Oct 2018 07:53:08 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7C23721D2E; Tue, 9 Oct 2018 03:53:04 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 09 Oct 2018 03:53:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=kWBs+IguE3Z//BxBrahbZ0+9Fex SedtTX6W0jVCK3yg=; b=SSiezqh1h+HGNA+ClYV5ZLtnmOKTWHmJ7cb0XgaoqOh hTNNaEsEcaLXUlWg4zSOh65rDNVwchtiuUocWO7USf4K9DHPYv5CgaYMwVgKdwq3 MvLOZ0q/IdbBblAOtZy5f/d5xM4JdI0IYJBOm2Z5OCMen/mbbFfRzWBEJmtSdKKU 7XqBqpdX3gRenf8HRXAJ35RosX+OjxzSveGd6Cmoyhvs6zjSqSSkD9qe/uTmE9qQ 6m2Cb8TDsVE0SbM+RTW7E18wpYu6A3xKNCGcQr04Bc0y++fwOD3oOb1ea8dMzCXm FjinrjOrNa2x0nIXsIXkAvG5+ueEOw3YRJn4mD6j5ww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=kWBs+I guE3Z//BxBrahbZ0+9FexSedtTX6W0jVCK3yg=; b=mTvVx1igneJV7IyD2wWZcG iJkETFfsia2UJEh9NLq6fHYx6ZbKIptfCj9sxiQfsAvjv6BkWawnZtoIjncDyk6h IPY4JTkFZrrgxOs9wT7a4UryEfsTBbj6VLBMU5Td1VnFkyT8Amou6QSBoArwclnh Zb8Sy5Tk571EK+fiPRDOcWgSIrawfQ97R7PilCnRFbuvqJczGoiNVCEV1GW+toWF vBtU/60dECpyr/NcS1+oyoNFSk+xlJm1U5z9G9SuONX+R7xpx0yJxHJbjaP6Or37 3nf14PJBD4ckrJgOUWpYTkdVzyt5J9vXxuVAraiSjh2XxfATU+xwQczd21GgmHBA == X-ME-Sender: X-ME-Proxy: Received: from paquier.xyz (c137162.net61215.cablenet.ne.jp [61.215.137.162]) by mail.messagingengine.com (Postfix) with ESMTPA id 799A7102D7; Tue, 9 Oct 2018 03:53:01 -0400 (EDT) Date: Tue, 9 Oct 2018 16:52:58 +0900 From: Michael Paquier To: Andres Freund Cc: Konstantin Knizhnik , pgsql-hackers@lists.postgresql.org, PostgreSQL Hackers Subject: Re: out-of-order XID insertion in KnownAssignedXids Message-ID: <20181009075258.GI2137@paquier.xyz> References: <0c96b653-4696-d4b4-6b5d-78143175d113@postgrespro.ru> <20181005080422.GA7863@paquier.xyz> <581a80f7-3992-f319-302d-7c9a384d64f7@postgrespro.ru> <2A819787-9E67-41EF-B89A-A906996924E5@anarazel.de> <20181008163049.nvaui5kjrsav2ojn@alap3.anarazel.de> <20181009055900.GH2137@paquier.xyz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6b3yLyRKT1M6kiA0" Content-Disposition: inline In-Reply-To: <20181009055900.GH2137@paquier.xyz> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --6b3yLyRKT1M6kiA0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Oct 09, 2018 at 02:59:00PM +0900, Michael Paquier wrote: > +1. I am looking at how to make that possible. And so... Going through a bit of investigation the problem is that each 2PC transaction preparing finishes by putting the procarray in a state where there are two entries referring to the same transaction running as MarkAsPrepared adds an extra entry on the top of the one already existing. This is expected though per the comments in ProcArrayClearTransaction(), as it assumes that MyProc can be safely cleaned and it assumes that there is a duplicated entry. Then, GetRunningTransactionData() ignores the assumption that those duplicate entries can exist, which makes the snapshot data taken as incorrect, generating those incorrect XLOG_RUNNING_XACT records. The most simple fix I can think of first is to tweak the origin of the problem in GetRunningTransactionData() so as those duplicate XIDs are ignored if found as there has to be a state between the time MarkAsPrepared() inserted the 2PC entry in the procarray and the time ProcArrayClearTransaction() gets called. -- Michael --6b3yLyRKT1M6kiA0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlu8XloACgkQnvQgOdby QH1Erw/+MSveOqnUkFMdp66ZEr+LD+mAS4niFV3LEGbMokOF+prHwKHlSuvK/K29 b8JCnGYEycZiNfyA05sUe3Ju+HscXnlnbFRU+Jm+EeuDC9vIr/kT2IRF10lNAllu pPY3A9M5ncfPiOIlemYop8tWYLkqZZZniMabZztw9igB6eCl8tmeptE+J80xEGqS 80OX6eK1UlaaPK6ONx0mtBHptZJ2jy+EzxRYniDX3NKHv1lW1aFNWRSJbljQjK03 OvNacbX+dQTVW00YpV0yBJvvYf5jrW9JuvOrfBUs3TSx8dinTazoFnKO+RRMIWeM 9qdXdYrzd2MSfx+4W5AJlfapvecqal783OCAteEQMgVRyGICNmN+zsnaglHRki8+ XJRc9t1Bt46ABixiZJugu1hbJ0jMqN4nQv4uG3jMG9290revR9ALfQP93HFyeLKI 5TzXgO2EWn9wYy5FyAxaNlYr10/1zqkg1lOJr6Jhz5B5tHj9ubXvS9ZRu/PA0PUr rRmiGCq+G5XGSEFlZk9dfPg/P5bL1kBNljPOGb5fJVFvEtHfKUlEdbECeqtvFAf9 LKJLSuFFzKU4ACi/sDCuvQBMeK2sL78DQcE4Onba3P+n4YllMW/5O+TjGcEDHeDj dqace8Bmb+3ODinOctp6m1F46KblXsn+xTUO+I9fMvNCiMCdeEE= =LRc7 -----END PGP SIGNATURE----- --6b3yLyRKT1M6kiA0--