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.96) (envelope-from ) id 1vWbmk-005kMJ-39 for pgsql-general@arkaria.postgresql.org; Fri, 19 Dec 2025 14:48:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vWbmj-007z5R-2T for pgsql-general@arkaria.postgresql.org; Fri, 19 Dec 2025 14:48:50 +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.96) (envelope-from ) id 1vWbmj-007z5J-1G for pgsql-general@lists.postgresql.org; Fri, 19 Dec 2025 14:48:50 +0000 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vWbmi-001WH7-1f for pgsql-general@lists.postgresql.org; Fri, 19 Dec 2025 14:48:49 +0000 Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-4775e891b5eso7680585e9.2 for ; Fri, 19 Dec 2025 06:48:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec.at; s=google; t=1766155727; x=1766760527; darn=lists.postgresql.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=vLv8j0aEemwvrIPFnW40lgUoZeawnoXTAE8Zpyg/fG0=; b=jASYG0ubnOnfvrIEP3TiCzzixvxz0TFeMWjLkkkDn/qh4dmVSTp3lrJONc0V/fgpW5 Miof1DLLPMyTHJApk1KsIRgGv8Zp5f+2ZibD0Pasena4tB3YBSPP3JaYZl5WNdmwFvsR WsoQo8uV0qbvPY+0MvjzvUgWYdyLIavc6hZzxUhypCuBKztr7swIuXqJ9qr7Gnn67Oqy PvW9CAiUfmUxbMFkQITIO+VLI2hR+Xxq4i/wgPQs30r9d7xEbtxNdmB6F72Mld8ErCK9 pNp9jcAO+U6AniFfoPQduBB4SjuSlVn+M1vqap6EJBSzpxt9/z7uS+mgE+xqHWqE1SUw i/OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766155727; x=1766760527; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vLv8j0aEemwvrIPFnW40lgUoZeawnoXTAE8Zpyg/fG0=; b=owXQhiBTThN5HSPXqP6/TsftME10GD+I3tTBzWfSR5gK/XCQKxj30+ZZpTeaWGw8Ks ODIJGFd60JIDRo1J4PxfkutQZRafKXk8EBbWp/kHjLhJdce7WB2sb8QXhc/Mbna2IexQ aiFaoBJpN+DpZv36HrIpx/DM66VwtDpRdOYLV7npdidC/d+EbEmhwBdx9ODv03nHTTju gvxbpErfPVtqPSwbJB7BMD5UElpPSCP3/F3hHj0u6a6bJmXDjO4mbyh29YTrqLSBdQQU 6mMzKLrYyRjDQzZsnMNjfLn/p+C4e7d3KXCPDLhhiNPvrUPG1EEbBHUSrJ/Yb6J/6+V1 mF6w== X-Forwarded-Encrypted: i=1; AJvYcCV6X/hpZSjqitnMXDH38BvgbY6Rw2avC/YkjgosLQ5SH2cjDKN+RTwJZgaHX88DxUWZNCh4EA7AGmE6jfOS@lists.postgresql.org X-Gm-Message-State: AOJu0Yz5VOMPBEXyjjRxW/WXcMbRGAaHK9snF3MFiyXALmudHPvSenZ9 VG4cXOJAb9qrXdS8/Wd/59sLPWdGeF3B8qmGqw8/JXz+KASpFDmCFWbDu4xFrcjl39A= X-Gm-Gg: AY/fxX7y9glEVuQ5wKOXmgNm2aEyOf9baFEKmGNsiUPvFlgR2sJ1wuvhTnVldN7ZlAi jLtkDZgmhuQ7tAPSAltwPeO5DYlLGA3ydjGuiaEcfi39bv38RZGb1gadZhLeBQ/U2QwCtrRhgwG gdVh6xkShiBrzQstJYL0SmxYpewA2OGEoNCdLB1ZKhwO5RHlZ/dGgXV8+Md2uuto3L3PNJFdiHb BHjXZFbJfTy2RdzKHQszxdRTJU3kvvrVEucyXqbD++mYkxK7iDgYHHeBmuGPH74GuYULliZqo+6 i4av99dOCyy2wLXpuG/5I8fGmNtb0BXsbWLFN+Hf11OORkjsrzyRaEhA9BRqwUWgoTGyMIdIewy EclVm4YWrotZgfNfklH6/eIhUnsXqozBoNv8x6hJJAmLQHVyLV4rYW5IPFeVOrqLmbwuQM/ybZn cMYoqcuzWoDe1rAk8FNTgxeX2dZaZnMm0mFm/8glCJ1g== X-Google-Smtp-Source: AGHT+IHCLCMbE5iC8c8/5oZ7sk+Qr1qiyn42R9OpBE/HOOniqW9SKasQeoQt2BjsKUtVFvuPwnmnjA== X-Received: by 2002:a05:600c:c08a:b0:47a:935f:618e with SMTP id 5b1f17b1804b1-47d197f65a6mr23304845e9.15.1766155726730; Fri, 19 Dec 2025 06:48:46 -0800 (PST) Received: from laurenz.albe-K4N0CV00F97414D ([2001:871:260:85ec:cf67:8776:2d1b:6b5d]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47be3a0fb9asm38453755e9.2.2025.12.19.06.48.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Dec 2025 06:48:46 -0800 (PST) Message-ID: <0e62db587431baddd981b7e1d1699df0d915bbaa.camel@cybertec.at> Subject: Re: wal segment size From: Laurenz Albe To: Colin 't Hart Cc: Andrew , Greg Sabino Mullane , PostgreSQL General Date: Fri, 19 Dec 2025 15:48:45 +0100 In-Reply-To: References: <4e2cfc51d3933a1df28e212ccb0b90f39633422a.camel@cybertec.at> <2890CAF1-6B00-440E-B8FF-3D333DFC5AF3@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2 (3.56.2-2.fc42) MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, 2025-12-19 at 14:25 +0100, Colin 't Hart wrote: > What's the behaviour when pg_resetwal is used to change the WAL segment s= ize? >=20 > This note is worrying to me: > -- > While pg_resetwal will set the WAL starting address beyond the latest exi= sting WAL segment file, some segment size changes can cause previous WAL fi= le names to be reused. It is recommended to use -l together with this optio= n to manually set the WAL starting address if WAL file name overlap will ca= use problems with your archiving strategy. > -- > Why can a segment size change cause previous WAL file names to be reused? >=20 > Do we need to take a new backup immediately after changing the WAL segmen= t size? I think that is supposed to mean that the new WAL numbering scheme might pr= oduce the same WAL segment name as a WAL segment name had long ago, so you might = overwrite that earlier segment in the WAL archive, which could prevent you from recov= ering from an old backup that needs the overwritten WAl segment to recover. I'm not sure how likely that is to happen. It never harms to run an extra backup. The main thing is that you shut down PostgreSQL cleanly before running "pg_= resetwal" and that you only change the WAL segment size, nothing else. Yours, Laurenz Albe