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 1fFGp3-0004lS-Bx for pgsql-hackers@arkaria.postgresql.org; Sun, 06 May 2018 10:23:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fFGoy-0005gw-FD for pgsql-hackers@arkaria.postgresql.org; Sun, 06 May 2018 10:23:12 +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 1fFGox-0005gm-Vt for pgsql-hackers@lists.postgresql.org; Sun, 06 May 2018 10:23:12 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by makus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fFGop-0001yL-Cb for pgsql-hackers@postgresql.org; Sun, 06 May 2018 10:23:09 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 1B58621C1E35; Sun, 6 May 2018 13:23:00 +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 [172.20.10.2] (unknown [213.87.137.19]) (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 841E021C1E2D; Sun, 6 May 2018 13:22:59 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1525602179; bh=gbrJP1+YVEQ1j6sokIocTz5SxB5lcr5ELPXWo1OQVxw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=JcBrnliY25jX4SdUB+aCa+7RA5LKqgIfgRrkDURbqqafy1Sul0vsNLJxWb7Km1Zdi WWYNzSGfSB8yWFPtKCJCe/eEAMtzirMqS1n331EWwovoHHQ0pWmLP+mZwCoODOMPKw kna5WAlxeZ/6cIDlmOKgwoC3kjv6FjXGszwafBTI= 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: Sun, 6 May 2018 13:22:57 +0300 Cc: PostgreSQL Hackers Content-Transfer-Encoding: 7bit Message-Id: References: <21BC916B-80A1-43BF-8650-3363CCDAE09C@postgrespro.ru> <5A30884C-F446-40FD-9D86-F4046F29F9F6@postgrespro.ru> To: Robert Haas X-Mailer: Apple Mail (2.3445.5.20) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk > On 4 May 2018, at 22:09, Robert Haas wrote: > > So, is the idea that we'll definitely find out about any remote > transactions within 30 seconds, and then after we know about remote > transactions, we'll hold back OldestXmin some other way? Yes, kind of. There is a procArray->global_snapshot_xmin variable which acts as a barrier to xmin calculations in GetOldestXmin and GetSnapshotData, when set. Also each second GetSnapshotData writes globalxmin (as it was before procArray->global_snapshot_xmin was taken into account) into a circle buffer with a size equal to global_snapshot_defer_time value. That more or less the same thing as with Snapshot Too Old feature, but with a bucket size of 1 second instead of 1 minute. procArray->global_snapshot_xmin is always set to oldest value in circle buffer. This way xmin calculation is always gives a value that were global_snapshot_xmin seconds ago and we have mapping from time (or GlobalCSN) to globalxmin for each second in this range. So when some backends imports global snapshot with some GlobalCSN, that GlobalCSN is mapped to a xmin and this xmin is set as a Proc->xmin. -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company