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 1fEHmb-0004aW-N8 for pgsql-hackers@arkaria.postgresql.org; Thu, 03 May 2018 17:12:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fEHma-0005tr-O5 for pgsql-hackers@arkaria.postgresql.org; Thu, 03 May 2018 17:12:40 +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 1fEHla-0000Pd-Hl for pgsql-hackers@lists.postgresql.org; Thu, 03 May 2018 17:11:38 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by makus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fEHlW-0007D2-HB for pgsql-hackers@postgresql.org; Thu, 03 May 2018 17:11:36 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 81D1B21C1C4B; Thu, 3 May 2018 20:11:31 +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 F05BE21C1C46; Thu, 3 May 2018 20:11:26 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1525367491; bh=eDuLHaD2+yR7mqY3k/07VdtVsapELOjXc+Q5JQaDWr4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=HPWbYRLLHUVQ3o55LJzTj1ZYgv8FOFI9jCn1fga8TaAfzsAhYP6sGSNsnOfdr/iI4 jO40SzRG40/ZNIEAzJ6ITZpioO8iL7O0gQoUrBjZC0XBZ3Rr0ZgYYzgWErFp6HSKOc VO7HVZGFMuv8aBHoscTTppXwm8xUbCFR15AWJV70= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Global snapshots From: Stas Kelvich In-Reply-To: Date: Thu, 3 May 2018 20:11:26 +0300 Cc: PostgreSQL Hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: <21BC916B-80A1-43BF-8650-3363CCDAE09C@postgrespro.ru> To: Masahiko Sawada X-Mailer: Apple Mail (2.3445.5.20) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk > On 3 May 2018, at 18:28, Masahiko Sawada = wrote: >=20 > On Wed, May 2, 2018 at 1:27 AM, Stas Kelvich = wrote: >> 1) To achieve commit atomicity of different nodes intermediate step = is >> introduced: at first running transaction is marked as InDoubt on = all nodes, >> and only after that each node commit it and stamps with a given = GlobalCSN. >> All readers who ran into tuples of an InDoubt transaction should = wait until >> it ends and recheck visibility. >=20 > I'm concerned that long-running transaction could keep other > transactions waiting and then the system gets stuck. Can this happen? > and is there any workaround? InDoubt state is set just before commit, so it is short-lived state. During transaction execution global tx looks like an ordinary running transaction. Failure during 2PC with coordinator not being able to commit/abort this prepared transaction can result in situation where InDoubt tuples will be locked for reading, but in such situation coordinator should be blamed. Same problems will arise if prepared transaction holds locks, for example. -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company