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 1g9Rur-0006Yx-AD for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Oct 2018 09:33:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g9Ruo-0002c8-VU for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Oct 2018 09:33:26 +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 1g9Ruo-0002c1-Kn for pgsql-hackers@lists.postgresql.org; Mon, 08 Oct 2018 09:33:26 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by makus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g9Rul-0001v8-4a for pgsql-hackers@postgresql.org; Mon, 08 Oct 2018 09:33:25 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id A3DF921C1E35; Mon, 8 Oct 2018 12:33:21 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-99 required=4 WHITELISTED tests=[] autolearn=unavailable Received: from [192.168.27.200] (gw.postgrespro.ru [93.174.131.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id 3BBB021C1E26; Mon, 8 Oct 2018 12:33:21 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1538991201; bh=HvRW9T6R7dLqiC0jUCXdCegHB4XmMPP2doJiAR3rCxQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=RBWkneYN+3csY1tud4jP6TQ3Nvp+x0C2PHq7PMq2qcsl5T/F0tRdbv/JGkFNMBICi Gj2p+HKzRrum3MWuw6tIE22rYhQjuuJW7pTN5ql2VSQXuAPwxviWsliapnQCzKFuuA ZGQ/AnzBBWl6oguT/xBGaflFUVBv7yBTReGN0GsE= Subject: Re: out-of-order XID insertion in KnownAssignedXids To: Michael Paquier Cc: PostgreSQL Hackers References: <0c96b653-4696-d4b4-6b5d-78143175d113@postgrespro.ru> <20181005080422.GA7863@paquier.xyz> <581a80f7-3992-f319-302d-7c9a384d64f7@postgrespro.ru> <20181008091451.GD2754@paquier.xyz> From: Konstantin Knizhnik Message-ID: <6ac20e7b-08a7-eb00-08f7-d332ec1f5605@postgrespro.ru> Date: Mon, 8 Oct 2018 12:33:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20181008091451.GD2754@paquier.xyz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 08.10.2018 12:14, Michael Paquier wrote: > On Mon, Oct 08, 2018 at 12:04:28PM +0300, Konstantin Knizhnik wrote: >> The simplest way to fix the problem is to ignore duplicates before adding >> them to KnownAssignedXids. >> We in any case perform sort i this place... > I may of course be missing something, but shouldn't we not have > duplicates in the first place? The reason of appearing duplicated XIDs in case of 2PC seems to be clear. It may be possible to eliminate it by clearing XID of MyPgxact for prepared transaction. But there are two problems with it: 1. I am not sure that it will not break something 2. There is obvious race condition between adding GXACT to ProcArrayAdd and invalidating XID of current transaction. If it is cleared before calling ProcArrayAdd, then there will be some moment when XID is not present in procarray. If it is done after calling ProcArrayAdd, then still it is possible to see duplicated XID in procarray. From my point of view it is easier and less invasive to exclude duplicates while replaying RUNNING_XIDS record. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company