Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1umD6c-00Bfsu-IU for pgsql-general@arkaria.postgresql.org; Wed, 13 Aug 2025 15:09:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1umD6b-00G0Ec-16 for pgsql-general@arkaria.postgresql.org; Wed, 13 Aug 2025 15:09:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1umD6a-00G0EU-5l for pgsql-general@lists.postgresql.org; Wed, 13 Aug 2025 15:09:32 +0000 Received: from fhigh-a1-smtp.messagingengine.com ([103.168.172.152]) by makus.postgresql.org with smtp (Exim 4.96) (envelope-from ) id 1umD6X-000Nlc-1H for pgsql-general@lists.postgresql.org; Wed, 13 Aug 2025 15:09:31 +0000 Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.phl.internal (Postfix) with ESMTP id 3A001140014D; Wed, 13 Aug 2025 11:09:29 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Wed, 13 Aug 2025 11:09:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1755097769; x=1755184169; bh=2PwU9GSz3KgpzNm2BUdcQFWwzswH1NwdDEBaZYsy3YA=; b= B55aKj+Jn//zQ88ALALk15kPNzS5xAZaVI1A8Li4GJ2RZ8yKjhzx9EpEBOKs9BzA x9viHDok2w2kA3XmGLP9TLXeIZdWdra+MXgveWcU4iuhEhTDAi345qcGMq1j1VQj +3c2OKNcmu+cZAxy0g6DvKrzyT1cvKgO4NaOD17mTFnkZFVsfnZVsYdlkTtR3f5g sosIFv9H9YTZYkXyZDf3b2lj2Gw9pGRVtIbm+eeOh478V87bP3IJ3iWJb/KZ6+xT ToYlpQS8oNnMYmy21PqA03T1ADNGBH9OcdFo+khFSlNhDW/+BCeIBRwM6sOKqujW QvpeCAa21t1y0QZ0pZXMFQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1755097769; x= 1755184169; bh=2PwU9GSz3KgpzNm2BUdcQFWwzswH1NwdDEBaZYsy3YA=; b=N /AiAfsbXadG9ztOLF05JYs5ItpML9UhlsjflYac9VEek86WE00qEoGHeidym94YQ GN+5mYyXW7J6U1Jhe+vqWLt42tHPkgJyZJceS6+3ZYXr7+9ZUMlISGr5fUfWtuCN TvdPqWtFeWF6vvM+3BdOiC0yhXlUdvQpkSJe9TP7TWozkX4P0yBzODNYghLip+my 0BbWfkbrq85LUxUEI+PRVv5V66BfGU9zbOYjaLchGEfKQdADJtdrhJYAOnV2SRnw mjZeXcj2wgPIqHDYIEkWm9aQRBJF8OITH2/4leXyNFYBF3yLEN659bbgZgf0c33X wgxB6HqWNknbRVwPFiqyQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddufeekheefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeetughrihgr nhcumfhlrghvvghruceorggurhhirghnrdhklhgrvhgvrhesrghklhgrvhgvrhdrtghomh eqnecuggftrfgrthhtvghrnhepfeegfeeiuedtgffgteeggfehkeejheetieeliefgteei keejvdeiveeigfehvedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheprggurhhirghnrdhklhgrvhgvrhesrghklhgrvhgvrhdrtghomhdpnhgs pghrtghpthhtohepgedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepshhpgihlhi ihuddvfeesghhmrghilhdrtghomhdprhgtphhtthhopeiiiiiiiiiirdhgrhgrfhesghhm rghilhdrtghomhdprhgtphhtthhopehrohhnlhhjohhhnhhsohhnjhhrsehgmhgrihhlrd gtohhmpdhrtghpthhtohepphhgshhqlhdqghgvnhgvrhgrlheslhhishhtshdrphhoshht ghhrvghsqhhlrdhorhhg X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 13 Aug 2025 11:09:28 -0400 (EDT) Message-ID: Date: Wed, 13 Aug 2025 08:09:27 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Questions about the continuity of WAL archiving To: px shi , Justin Cc: Ron Johnson , "pgsql-generallists.postgresql.org" References: <73f3723b-f279-43c6-884d-d12b3151ec9e@aklaver.com> Content-Language: en-US From: Adrian Klaver In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 8/12/25 22:48, px shi wrote: > Here’s a scenario: The latest WAL file on the primary node is > 0000000100000000000000AF, and the standby node has also received up to > 0000000100000000000000AF. However, the latest WAL file that has been > successfully archived from the primary is only 0000000100000000000000A1 > (WAL files from A2 to AE have not yet been archived). If the primary > crashes at this point, triggering a failover, the new primary will start > generating and archiving WAL on a new timeline (2), beginning with > 0000000200000000000000AF. It will not backfill the missing WAL files > from timeline 1 (0000000100000000000000A2 to 0000000100000000000000AE). > As a result, while the new primary does not have any local WAL gaps, the > archive directory will contain a gap in that WAL range. > I’m not sure if I explained it clearly. Why does it matter? 1) Your standby is starting off up to date. 2) You can do a pg_basebackup from the new primary as a base for the restart of the old primary. Assuming you have archiving set up on the new primary then the restarted primary can catch up. 3) If you don't want to do 2) then you need an archive location that can deal with the velocity of the WAL archiving. > > > Justin > 于2025年8月 > 13日周三 10:51写道: > -- Adrian Klaver adrian.klaver@aklaver.com