Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 2C29D634BC0 for ; Thu, 1 Oct 2009 11:36:12 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 92004-09 for ; Thu, 1 Oct 2009 14:36:04 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail128148.authsmtp.net (outmail128148.authsmtp.net [62.13.128.148]) by mail.postgresql.org (Postfix) with ESMTP id 1B8406349FC for ; Thu, 1 Oct 2009 11:36:03 -0300 (ADT) Received: from mail-c193.authsmtp.com (mail-c193.authsmtp.com [62.13.128.118]) by punt5.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id n91EZw81057647; Thu, 1 Oct 2009 15:35:58 +0100 (BST) Received: from [192.168.0.5] (88-110-190-77.dynamic.dsl.as9105.com [88.110.190.77]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id n91EZrYF003902; Thu, 1 Oct 2009 15:35:54 +0100 (BST) Subject: Re: Hot Standby on git From: Simon Riggs To: Heikki Linnakangas Cc: pgsql-hackers In-Reply-To: <4AC49281.2040302@enterprisedb.com> References: <1253958559.4449.833.camel@ebony.2ndQuadrant> <4AC49281.2040302@enterprisedb.com> Content-Type: text/plain Date: Thu, 01 Oct 2009 15:39:27 +0100 Message-Id: <1254407967.17864.229.camel@ebony.2ndQuadrant> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Server-Quench: b993bb68-ae97-11de-90cd-002264978518 X-Report-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCdxZQATClZOTQEd DAteCiN5VAwpPBRK HVkIKg5MJUcNSQVJ NksadBtFaARbYlpF HGQLW11EUVh7WmZ/ bg4fZQ1DY0tOQQRj UFZORU1QEQdtHhxP WBcfJ3MwHnNGeH15 ZUQsWnVZXAoofE9+ EBxSHXBXMG5ndWEe BBVFfgMHJB5Kfh1H bFR2U3sIYG1JBC9q VzwTFhsSEA9kHWx1 RR1FFk4bR0oBD3Y7 QVgNHClH X-Authentic-SMTP: 61633235383639.1014:706/Kp X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5 tests=BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 200910/44 X-Sequence-Number: 146856 On Thu, 2009-10-01 at 14:29 +0300, Heikki Linnakangas wrote: > + /* > + * If our initial RunningXactData had an overflowed snapshot then we > + * knew we were missing some subxids from our snapshot. We can use > + * this data as an initial snapshot, but we cannot yet mark it valid. > + * We know that the missing subxids are equal to or earlier than > + * LatestRunningXid. After we initialise we continue to apply changes > + * during recovery, so once the oldestRunningXid is later than the > + * initLatestRunningXid we can now prove that we no longer have > + * missing information and can mark the snapshot as valid. > + */ > + if (initRunningXactData && !recoverySnapshotValid) > + { > + if (TransactionIdPrecedes(initLatestRunningXid, > xlrec->oldestRunningXid) > + { > + recoverySnapshotValid = true; > + elog(trace_recovery(DEBUG2), > + "running xact data now proven complete"); > + elog(trace_recovery(DEBUG2), > + "recovery snapshots are now enabled"); > + } > + return; > + } > + > > When GetRunningXactData() calculates latestRunningXid in the master, > which is stored in initLatestRunningXid in the standby, it only looks at > xids and subxids present in the procarray. It doesn't take into account > overflowed subxids. I think we could declare a recovery snapshot "proven > complete" too early because of that. Hmm, yes. ISTM that I'm still calculating latestRunningXid the old way while assuming it is calculated the new way. The new way is just to grab nextXid since we have XidGenLock and do TransactionIdRetreat() on it. -- Simon Riggs www.2ndQuadrant.com