Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtvOM-00042u-MA for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Nov 2015 10:34:10 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZtvOM-0004vq-7k for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Nov 2015 10:34:10 +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) (envelope-from ) id 1ZtvOK-0004rd-41 for pgsql-hackers@postgresql.org; Wed, 04 Nov 2015 10:34:08 +0000 Received: from mail.anarazel.de ([217.115.131.40]) by magus.postgresql.org with esmtp (Exim 4.84) (envelope-from ) id 1ZtvOH-0006dR-Jj for pgsql-hackers@postgresql.org; Wed, 04 Nov 2015 10:34:07 +0000 Received: by mail.anarazel.de (Postfix, from userid 108) id EFFC1860002; Wed, 4 Nov 2015 11:34:03 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from anarazel.de (p54895FAC.dip0.t-ipconnect.de [84.137.95.172]) (Authenticated sender: andres@anarazel.de) by mail.anarazel.de (Postfix) with ESMTPSA id 93A30860001; Wed, 4 Nov 2015 11:33:51 +0100 (CET) Received: by anarazel.de (Postfix, from userid 1000) id 271D0100823; Wed, 4 Nov 2015 11:33:51 +0100 (CET) Date: Wed, 4 Nov 2015 11:33:51 +0100 From: Andres Freund To: Michael Paquier Cc: Robert Haas , Jeff Janes , "pgsql-hackers@postgresql.org" Subject: Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby Message-ID: <20151104103351.GB29170@awork2.anarazel.de> References: <20151016203031.3019.72930@wrigleys.postgresql.org> <20151102055841.2561.61366.pgcf@coridan.postgresql.org> <20151103154300.GY11897@awork2.anarazel.de> <741137DB-35AF-450B-9746-7FE55A8729C3@anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Pg-Spam-Score: -4.2 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 2015-11-04 16:01:28 +0900, Michael Paquier wrote: > On Wed, Nov 4, 2015 at 8:39 AM, Andres Freund wrote: > > On November 4, 2015 12:37:02 AM GMT+01:00, Michael Paquier wrote: > >>On a completely idle system, I don't think we should log any standby > >>records. This is what ~9.3 does. > > > > Are you sure? I think it'll around checkpoints, no? I thought Heikki had fixed that, but looking sound that doesn't seem to be the case. > > Er, yes, sorry. I should have used clearer words: I meant idle system > with something running nothing including internal checkpoints. Uh, but you'll always have checkpoints happen on wal_level = hot_standby, even in 9.3? Maybe I'm not parsing your sentence right. As soon as a single checkpoint ever happened the early-return logic in CreateCheckPoint() will fail to take the LogStandbySnapshot() in CreateCheckPoint() into account. The test is: if (curInsert == ControlFile->checkPoint + MAXALIGN(SizeOfXLogRecord + sizeof(CheckPoint)) && ControlFile->checkPoint == ControlFile->checkPointCopy.redo) which obviously doesn't work if there's been a WAL record logged after the redo pointer has been determined etc. The reason that a single checkpoint is needed to "jumpstart" the pointless checkpoints is that otherwise we'll never have issued a LogStandbySnapshot() and thus the above code block works if we started from a proper shutdown checkpoint. Independent of the idle issue, it seems to me that the location of the LogStandbySnapshot() is actually rather suboptimal - it really should really be before the CheckPointGuts(), not afterwards. As closer it's to the redo pointer of the checkpoint a hot standby node starts up from, the sooner that node can reach consistency. There's no difference for the first time a node starts from a basebackup (since we gotta replay that checkpoint anyway before we're consistent), but if we start from a restartpoint... Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers