Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pEu3L-00032s-IV for pgsql-admin@arkaria.postgresql.org; Mon, 09 Jan 2023 15:27:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pEu3K-0001jn-Gy for pgsql-admin@arkaria.postgresql.org; Mon, 09 Jan 2023 15:27:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pEu2l-00045y-G3 for pgsql-admin@lists.postgresql.org; Mon, 09 Jan 2023 15:26:35 +0000 Received: from sonic322-46.consmr.mail.gq1.yahoo.com ([98.137.70.109]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pEu2j-0002WW-0s for pgsql-admin@lists.postgresql.org; Mon, 09 Jan 2023 15:26:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673277989; bh=dSvG1eys0kgZwXRfH2HNZSSG8vHsK9fBx2sIfmCETaQ=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=rzEkZddNyF/9BA+MzWOygyHoP7zT4ZsvQQtN8g5XPcTPiZPMSjL1rYlCgWcj/JuPD1BiHO85Kx3e0YN8S7IgRfDIwTxpo54FJhRzZX+gOVwoOlFDY4VoDzm3OLTA3BcnP9MdbK4yeIdKHy3iFOFw8O3QXbRgiH6cXA7si/x57K1KBiKSzTPSyVZ9EUvBcsftdaK2fvsQTyvTJ3YOLnhGWU4YRuaO3YvoVrN8Q2gU3g17B4xTgpJ4lYpn+3HsBSB8DcMtHKAb4qFojsEw9/Q5sq5XiBiaUS4fONjOMZy1dCk1euU5cv1p+vCI5Sj+vXzKTXPVhWZ+/9EfvUR1UJpxjQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673277989; bh=g59VFNtrAcf91P97aaUVgcf9XvNYq3KovW/FkH2MTnv=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=I/qdJXSjQUn2bbm2uZronT1zWJN+KsLn0mxJ6y8Ojg4AdmI8pP4tcd2oVSrThOLs9z+O1TXDlTSu+jlfP7SCewbe9JOeo2XB/BIduqBdZLmk8isXzLshMORcX00HCn6s8e4xESPUsahKheL4dVCsOwRoSOxj3UUth+q5oF+svKUQVuex6V0qKZtai8Fx9GAFijklbzx86qDR7+H43uC9M1p8kDe58tvlm3ZUr3gMKLRunGYT8XJ734P760lkhmPVS4ndS9NVBWoSG/kH5r8MJJtMoCyBL/83TdKgfaXRlAN7H8H06Grd3Djp5PihhXb5L5RUA3OBK2rpQ39pMEJUWg== X-YMail-OSG: pEDD5GIVM1nNyvraLWy6rRDloqcu.vb4ql0SayZX.erM26i01ch7TZVsf90bqZL A8wf_uPRW1mejdeNMIIxD3grcvdQo7hxkEmSUBpcaU7xmlJ7VV.3dXtc2EEfGgp32dm0pl2A7yZm wWrqckeEimaCrkCY7Yg2wZlgTfmG1fcn5x1Q5gFZiKJHz2EMSIRtOoHOrbywVq940fTc2axQMu59 VwV6A3mJx3MyOSj0Lpu8Lht0Ndcbe_e23pbp6PjhvWxmq_M5ac0kKO.PLT.Dgr0lzXae5LHclqQo uwD1lYOfNpqTRrQzKllGcuXT82qIMW4Vu04MsyMoEpUXFLi5iaPkA2IWs2x0y_2PYEkcB90ZvFX4 VHOsuIJO9HVQggyEEMbO7dqSAnPhqe9OMTTLBNP1kKcO7xe5ubZVo79AJUkKRTXoBU4Qgs1yEbGk yXJwZ.zuui4Ha1ajCx3Y1or9CuEdYOTkc1neVpsH7ElXydvCIlh26KUoxbgljKJ70q2_qFqHVn6h RJeI19KT6uPubvlmyy1CTq8AtyiR3ZXz.HR6nLZ9tnxxFbKy71OYjuW2sK7kT4Z9EarjrVL3l1WV W7CT5e2cCX_xDrNMb9DJIaaHk_wpQxKPKkQoXXXUTjnTy3h5Rk1leTUXf44Qx1YwlRZoFQma79D5 2lzgrKtltS1qi24HpIeC31bQ.Dudt4k.6pzvO9Im6XWjQUZcQa8AQv0xdz647JL2fZ3lO2dhsF8i midLQw8OEQnAI4B7TfyGVj9NTTqKj6M7VtwBuSS26uylah4_2Kg9EZ.e8nFtLzwJN.soYAymfvnY ApcwlHGoQwIBJVi5Rj_nzXrULxdke_fSgde9inJZd7Kx.EI47cr.wLmDoYidUIvhUceAkIxXTMSN Rn0F.qrHgwSWDuq_zo.O05kBVXghh96cwkQwH3JThU8BlK_mfDyJLsIwpJJYkfhHysFd5agCv1hP j7IL3bpnvC8S57StVrrFCrcaq6V.62jZtoDnWocvIfc2aJ7ofBQvNPjoaKQAMnnUlH4aE_6AWFbU 7FGV81ApxLS1KAiDH_S6sexGzadTZSKyCn2rz2yZGAGt9lFiTEGuzZVXrniKSXH1UUALodJrDR8T .AKl2gOo0xCYSCccvfgHu3Cna1_Tc_z2yKWYCJCW7A6uIs9lZ8.mhjVrg2pcOXMtc6KTeD.PCkis gSqZtCKYW6l5hi.w2hbPQTXqBgp0RTbRbr4qeySNoAQ9LJFfD6AK.2H8tDtR63UxCASxyDpBmU1o iGU1HL2MfBqEh.jFqVsQ9rLoaR2vqJamKDMirOa3OnsoBMZidRzpUKkPT_C8dCnInp7eB8J0hMfb n38wx5j0JR3a5m1OvW1bkfgMc5CBa.M4hCSNQFQoef9ywot9LeRjqber_SYjXZBZUv9c1h0685mJ iWEbGqdiKdW8.yXxJw7fpTLe.6upkaUC9U2gfpuj2h166RdlNjGAGuw3jghTJs.mEx7cE97XgTQV Ho8LDnL14rudOb3e9sINTy3bn57.4Q6wxxj6NEnZn_l_kc4yFEaRlK.T0IL7XpH6OY9O6QBiHEJq zaJh4MohIoWi7fB849cq2IHNIDfeR2v36BfyHD7O2CuaxW9tjbMkJLTb2JumYmEvcRpqeNidHXHf j7ukNZ1vuh6LohCE6wb2WRP_xTkPodPlC21v.brbAsscK_SWDUXmI6hqigsrbsN1xl1fInpNPKpX s5_nWVYMl6c9lPUV4daB.w9auO9dBuNEyshqTQ3m6nSkR6NoGkOWRAJVgaLioPbC5f9VvIwHd5fQ oDWG5nOdxjtp8UXvUJIE9MNsNJGzJoWcHNYVrO2vOmWEtYd4.Auj2SRaoaO.I.chWLo_9mX9EeOV zSHD5rux_Y306T4kUaYg0Ciw9_nHuGXIjjkysr164BMcqh.Y87Re8LcwE3USoL9rdhIJwOCUhMMF xpq9cPgf0OBi9av5BvwlMGJXPQ99B4ck9PvXj5bu9EX.Kln4rJO1hQp4JnWZvftdQ6HiU.IInMKY _t0Nqe7YR9GKXWIkb7xR9OXzDRqg24wPnP3oN2hPiCHuGHXb8txIP6D2Q0.ti57fG38RPrex5weN fsM52Xxa0I9rQZBfmQL9FvsqbEKbFaeu_yaYmNwlgvKvwdOG32UXpx6h6ZXECDT4AALH5j3hrK.X 40NvlWQg53nINIsVj94QEOq13OfgOlAZ.fK9Q4iZBlFOHoxlh7fzNvIdBymeW X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic322.consmr.mail.gq1.yahoo.com with HTTP; Mon, 9 Jan 2023 15:26:29 +0000 Date: Mon, 9 Jan 2023 15:24:27 +0000 (UTC) From: Alexander Pogodin To: "pgsql-admin@lists.postgresql.org" Message-ID: <1254601719.7524472.1673277867599@mail.yahoo.com> Subject: Cascaded Replication question MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7524471_459646702.1673277867598" References: <1254601719.7524472.1673277867599.ref@mail.yahoo.com> X-Mailer: WebService/1.1.20982 YMailNorrin Content-Length: 2625 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_Part_7524471_459646702.1673277867598 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, guys! I have a setup with 3 PgSQL instances connected with streaming replication = as such: +---+=C2=A0=C2=A0=C2=A0=C2=A0 +---+=C2=A0=C2=A0=C2=A0=C2=A0 +---+ | A | <-- | B | <-- | C | +---+=C2=A0=C2=A0=C2=A0=C2=A0 +---+=C2=A0=C2=A0=C2=A0=C2=A0 +---+ When the link to A is broken, I manually promote server B and expect server= C to follow new timeline: I have recovery_target_timeline set to latest. B= ut that's not the case. To follow new timeline I have to restart server C. = Is it the designed behavior or am I missing something? I am using the latest 10.x version.=20 Could you, please, advise? Best regards, Alex Pogodin. ------=_Part_7524471_459646702.1673277867598 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello= , guys!

I have a setup with 3 PgSQL instances connected with strea= ming replication as such:

+---+     +--= -+     +---+
| A | <-- | B = | <-- | C |
+---+     +---+=      +---+

When the link to A is broken, I manually pro= mote server B and expect server C to follow new timeline: I have recovery_target_timeline set to= latest. But that's not the= case. To follow new timeline I have to restart server C. Is it the designe= d behavior or am I missing something?

I am using the latest 10.x versio= n.

Could you, please, advise?


Best regards, Alex Pogodin.
------=_Part_7524471_459646702.1673277867598--