Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 1BD4CB5DBEE for ; Tue, 5 Jul 2011 16:50:35 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 15390-01 for ; Tue, 5 Jul 2011 19:50:24 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from midnight-anchovy.ambulatoryclam.net (unknown [18.141.0.210]) by mail.postgresql.org (Postfix) with ESMTP id DB46DB5DBCE for ; Tue, 5 Jul 2011 16:50:23 -0300 (ADT) Received: by midnight-anchovy.ambulatoryclam.net (Postfix, from userid 1001) id D8C864AC26; Tue, 5 Jul 2011 15:54:36 -0400 (EDT) Date: Tue, 5 Jul 2011 15:54:36 -0400 From: Dan Ports To: Kevin Grittner Cc: Heikki Linnakangas , pgsql-hackers@postgresql.org Subject: Re: SSI atomic commit Message-ID: <20110705195436.GB94047@csail.mit.edu> References: <4E12FDA8020000250003EFC1@gw.wicourts.gov> <4E13516F.50301@enterprisedb.com> <4E130E61020000250003EFD8@gw.wicourts.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E130E61020000250003EFD8@gw.wicourts.gov> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.107 tagged_above=-5 required=5 tests=BAYES_00=-1.9, RDNS_NONE=0.793 X-Spam-Level: X-Archive-Number: 201107/232 X-Sequence-Number: 191331 On Tue, Jul 05, 2011 at 01:15:13PM -0500, Kevin Grittner wrote: > Heikki Linnakangas wrote: > > > Hmm, I think it would be simpler to decide that instead of > > SerializableXactHashLock, you must hold ProcArrayLock to access > > LastSxactCommitSeqNo, and move the assignment of commitSeqNo to > > ProcArrayTransaction(). It's probably easiest to move > > LastSxactCommitSeqno to ShmemVariableCache too. There's a few > > places that would then need to acquire ProcArrayLock to read > > LastSxactCommitSeqno, but I feel it might still be much simpler > > that way. > > We considered that. I think the biggest problem was that when there > is no XID it wouldn't be covered by the lock on assignment. One other issue is that after the sequence number is assigned, it still needs to be stored in MySerializableXact->commitSeqNo. Modifying that does require taking SerializableXactHashLock. With the proposed patch, assigning the next commitSeqNo and storing it in MySerializableXact happen atomically. That makes it possible to say that a transaction that has a commitSeqNo must have committed before one that doesn't. If the two steps are separated, that isn't true: two transactions might get their commitSeqNos in one order and make them visible in the other. We should be able to deal with that, but it will make some of the commit ordering checks more complicated. Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/