Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ejlY3-0004M9-3X for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Feb 2018 12:43:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ejlY1-00061V-Vt for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Feb 2018 12:43:29 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ejlY1-00061L-Iw for pgsql-hackers@lists.postgresql.org; Thu, 08 Feb 2018 12:43:29 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by magus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ejlXy-0001iL-J0 for pgsql-hackers@postgresql.org; Thu, 08 Feb 2018 12:43:28 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 9A10821C1F72; Thu, 8 Feb 2018 15:43:24 +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.93] (gw.postgrespro.ru [93.174.131.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id 397A421C1F70; Thu, 8 Feb 2018 15:43:24 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1518093804; bh=E3hzNng9Q2vV4+NvC94M5rOpIX0MoDH0k9BT5DYl0qU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Q3eKCI+BmWnD/N3N7mpye8GYNq4wfK+UB7XMox0K+vKVOo+k4GOT1pcLL4mpsLe1q +rqnqGJ9X6ktkyiTDCObzO+qxZ0yni3FQRCEnGn3TvkliDo+I921r3qEqkq9vkVDEb PUp8S3msfokBRvvrg/7j84tsRjHyn8+xvi+1Hd84= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: [HACKERS] logical decoding of two-phase transactions From: Stas Kelvich In-Reply-To: Date: Thu, 8 Feb 2018 15:43:23 +0300 Cc: Peter Eisentraut , Simon Riggs , Craig Ringer , Petr Jelinek , Sokolov Yura , Andres Freund , Dmitry Dolgov <9erthalion6@gmail.com>, Tom Lane , Masahiko Sawada , PostgreSQL Hackers , Robert Haas Content-Transfer-Encoding: quoted-printable Message-Id: <11AEF68F-14A2-4662-AAEE-87422ADA3864@postgrespro.ru> References: <45525c30-4002-861e-a82c-3b95b19d1514@2ndquadrant.com> To: Nikhil Sontakke X-Mailer: Apple Mail (2.3445.5.20) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi! Thanks for working on this patch. Reading through patch I=E2=80=99ve noticed that you deleted call to = SnapBuildCommitTxn() in DecodePrepare(). As you correctly spotted upthread there was = unnecessary code that marked transaction as running after decoding of prepare. = However call marking it as committed before decoding of prepare IMHO is still needed = as SnapBuildCommitTxn does some useful thing like setting base snapshot for = parent transactions which were skipped because of SnapBuildXactNeedsSkip(). E.g. current code will crash in assert for following transaction: BEGIN; SAVEPOINT one; CREATE TABLE test_prepared_savepoints (a int); PREPARE TRANSACTION 'x'; COMMIT PREPARED 'x'; :get_with2pc_nofilter :get_with2pc_nofilter <- second call will crash decoder With following backtrace: =20 frame #3: 0x000000010dc47b40 = postgres`ExceptionalCondition(conditionName=3D"!(txn->ninvalidations =3D=3D= 0)", errorType=3D"FailedAssertion", fileName=3D"reorderbuffer.c", = lineNumber=3D1944) at assert.c:54 frame #4: 0x000000010d9ff4dc = postgres`ReorderBufferForget(rb=3D0x00007fe1ab832318, xid=3D816, = lsn=3D35096144) at reorderbuffer.c:1944 frame #5: 0x000000010d9f055c = postgres`DecodePrepare(ctx=3D0x00007fe1ab81b918, buf=3D0x00007ffee2650408,= parsed=3D0x00007ffee2650088) at decode.c:703 frame #6: 0x000000010d9ef718 = postgres`DecodeXactOp(ctx=3D0x00007fe1ab81b918, buf=3D0x00007ffee2650408) = at decode.c:310 That can be fixed by calling SnapBuildCommitTxn() in DecodePrepare() which I believe is safe because during normal work prepared transaction holds relation locks until commit/abort and in between nobody can access altered relations (or just I don=E2=80=99t know such situations =E2=80=94 = that was the reason why i had marked that xids as running in previous versions). > On 6 Feb 2018, at 15:20, Nikhil Sontakke = wrote: >=20 > Hi all, >=20 >>=20 >> PFA, patch which applies cleanly against latest git head. I also >> removed unwanted newlines and took care of the cleanup TODO about >> making ReorderBufferTXN structure using a txn_flags field instead of >> separate booleans for various statuses like has_catalog_changes, >> is_subxact, is_serialized etc. The patch uses this txn_flags field = for >> the newer prepare related info as well. >>=20 >> "make check-world" passes ok, including the additional regular and = tap >> tests that we have added as part of this patch. >>=20 >=20 > PFA, latest version of this patch. >=20 > This latest version takes care of the abort-while-decoding issue along > with additional test cases and documentation changes. >=20 >=20 -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company