Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eKCum-0008Mt-Vf for pgsql-admin@arkaria.postgresql.org; Thu, 30 Nov 2017 00:41:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eKCul-0003ZZ-Um for pgsql-admin@arkaria.postgresql.org; Thu, 30 Nov 2017 00:41:19 +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_2) (envelope-from ) id 1eKCul-0003ZP-Dg for pgsql-admin@lists.postgresql.org; Thu, 30 Nov 2017 00:41:19 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eKCud-00007f-Lh for pgsql-admin@postgresql.org; Thu, 30 Nov 2017 00:41:18 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7B3D820A5B; Wed, 29 Nov 2017 19:41:09 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 29 Nov 2017 19:41:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=Jt4CJprJlNllAnemep5dvRkhOxGcf QVf/+X5LH1Ni7w=; b=parE0VaV8wuT8/Ui0u0UEPOyZInCjA4kiGJkx0rlYAPxR ouIZke8AJNPyHc489e23wB3aNyXYkwbxwL6CCKZwuLMyyYOPN53eb1Kp8I0ViwTz 5GrL+m+G3voMSUcRW6c3F2vB6RKgLCjvONFVbN43/OJ6aCEP9y2INqWft9knJO9Z 60pVcJ+vid9qKpJ1D0sP3PvGg1e/F07xLWQldLszEESLE9ATt0wPm4gY/UaGiwYI 2fYL3+xDzpeelc4zRP+q5Pw9m0W/xzbZEaqDfd4Aa+hXTtTu/iQoXFIRAPkhNsxk 1wgQ+1y+dbnQH6hViV4askuQXJKb7QTV4jpQINyYg== X-ME-Sender: Received: from intern.anarazel.de (unknown [136.24.76.189]) by mail.messagingengine.com (Postfix) with ESMTPA id 09E57240F6; Wed, 29 Nov 2017 19:41:09 -0500 (EST) Date: Wed, 29 Nov 2017 16:41:07 -0800 From: Andres Freund To: Alvaro Herrera Cc: Alex Kliukin , pgsql-admin@postgresql.org Subject: Re: 'replication checkpoint has wrong magic' on the newly cloned replicas Message-ID: <20171130004107.j2ve7qn2ene7fqhm@alap3.anarazel.de> References: <1511966240.1459861.1188109744.2D26AD08@webmail.messagingengine.com> <20171129232243.vk5ik5szknppo3it@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171129232243.vk5ik5szknppo3it@alvherre.pgsql> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 2017-11-29 20:22:43 -0300, Alvaro Herrera wrote: > Alex Kliukin wrote: > > > 2017-11-15 13:15:46.673 CET,,,15154,,5a0c2ff1.3b32,5,,2017-11-15 > > 13:15:45 CET,,0,PANIC,XX000,"replication checkpoint has wrong magic > > 5714534 instead of 307747550",,,,,,,,,"" > > Uhh ... I had never heard of this "replication checkpoint" thing. Contains information about how far logical replication like solutions have replayed from other systems. > It is part of replication origins feature, which is fairly new stuff > (see src/backend/replication/logical/origin.c). I'd bet this problem > is related to a bug in logical replication "origins" code rather than > any procedural problems in your base-backup taking setup ... Possible. What's the max_replication_origins setting? Is the system receiving logical replication data? Could you describe the setup a bit? Any chance the system's partially been running without fsync? Could you attach both a corrupt and a non-corrupt state file? It's a bit weird to see such an error because normally the state file's just written to a temporary file and then renamed into place, overwriting the old file. > I wonder if there is some truncation of the 0x1257DADE value that > produces the 5714534 value you're seeing -- something related to a > pg_logical/replorigin_checkpoint file being written partially while the > backup is being taken. > > Another point towards not including pg_logical/ contents when taking a > base backup, I guess ... You'd cause corruption if logical replication is in use, so no, please don't. - Andres