MIME-Version: 1.0
References: <CAAccyYKpNsQMD+S-A7a8YtDevFN0uRXkzg4tYWWBOFsv_jASNg@mail.gmail.com>
 <CAKAnmmJPGgEp2kKPomhq7P=GUA5HD1eOaP5X+7c68gm5f4YVqQ@mail.gmail.com>
In-Reply-To: <CAKAnmmJPGgEp2kKPomhq7P=GUA5HD1eOaP5X+7c68gm5f4YVqQ@mail.gmail.com>
From: Ron Johnson <ronljohnsonjr@gmail.com>
Date: Fri, 8 Aug 2025 14:45:02 -0400
Message-ID: <CANzqJaBdhehezNtnaC_=08abyozUTo=YwW-Ma1PAzx-mg56Rgg@mail.gmail.com>
Subject: Re: Questions about the continuity of WAL archiving
To: "pgsql-generallists.postgresql.org" <pgsql-general@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000616ca7063bdef917"
Archived-At: <https://www.postgresql.org/message-id/CANzqJaBdhehezNtnaC_%3D08abyozUTo%3DYwW-Ma1PAzx-mg56Rgg%40mail.gmail.com>
Precedence: bulk

--000000000000616ca7063bdef917
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 8, 2025 at 2:26=E2=80=AFPM Greg Sabino Mullane <htamfids@gmail.=
com>
wrote:

> There is a scenario: the current timeline of the PostgreSQL primary node
>> is 1, and the latest WAL file is 100. The standby node has also received=
 up
>> to WAL file 100. However, the latest WAL file archived is only file 80. =
If
>> the primary node crashes at this point and the standby is promoted to th=
e
>> new primary, archiving will resume from file 100 on timeline 2. As a
>> result, WAL files from 81 to 100 on timeline 1 will be missing from the
>> archive.
>> Is there a good solution to prevent this situation?
>>
>
> I'm still not clear on what the problem here is, other than your archivin=
g
> not keeping up. The best solution to that is:
>
>
> https://pgbackrest.org/1/configuration.html#section-archive/option-archiv=
e-async
>
> Yes, you would lost some ability for easy PITR for 80-100, but could stil=
l
> be done by resurrecting your crashed primary, or carefully grabbing from
> the replica before they get recycled. You can set archive_mode=3Dalways o=
n
> the replicas to help with this.
>

Bog-standard PgBackRest retains all WAL files required for a full backup
set and its associated differential/incremental backups, no?  I've
certainly done more than one --type=3Dtime --target=3D"${RestoreUntil}" res=
tore
without giving a second thought to timelines or whether the WAL exists.

Maybe I've just ignored the problem, since it (seemingly) does everything
for PITR backups.

--=20
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

--000000000000616ca7063bdef917
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Aug 8, 2025 at 2:26=E2=80=AFPM Gr=
eg Sabino Mullane &lt;<a href=3D"mailto:htamfids@gmail.com">htamfids@gmail.=
com</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_container"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div>There is a scenario: the current timeline of the PostgreSQL p=
rimary node is 1, and the latest WAL file is 100. The standby node has also=
 received up to WAL file 100. However, the latest WAL file archived is only=
 file 80. If the primary node crashes at this point and the standby is prom=
oted to the new primary, archiving will resume from file 100 on timeline 2.=
 As a result, WAL files from 81 to 100 on timeline 1 will be missing from t=
he archive.<br>Is there a good solution to prevent this situation?</div></d=
iv></blockquote><div><br></div><div>I&#39;m still not clear on what the pro=
blem here is, other than your archiving not keeping up. The best solution t=
o that is:</div><div><br></div><div><a href=3D"https://pgbackrest.org/1/con=
figuration.html#section-archive/option-archive-async" target=3D"_blank">htt=
ps://pgbackrest.org/1/configuration.html#section-archive/option-archive-asy=
nc</a></div><div><br></div><div>Yes, you would lost some ability for easy P=
ITR for 80-100, but could still be done by resurrecting your crashed primar=
y, or carefully grabbing from the replica before they get recycled. You can=
 set archive_mode=3Dalways on the replicas to help with this.</div></div></=
div></blockquote><div></div></div><div><br></div><div>Bog-standard PgBackRe=
st retains all WAL files required for a full backup set and its associated =
differential/incremental backups, no?=C2=A0 I&#39;ve certainly done more th=
an one=C2=A0--type=3Dtime --target=3D&quot;${RestoreUntil}&quot; restore wi=
thout giving a second thought to timelines or whether the WAL exists.</div>=
<div><br></div><div>Maybe I&#39;ve just ignored the problem, since it (seem=
ingly) does everything for PITR backups.=C2=A0</div><div><br></div><span cl=
ass=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmai=
l_signature"><div dir=3D"ltr">Death to &lt;Redacted&gt;, and butter sauce.<=
div>Don&#39;t boil me, I&#39;m still alive.<br><div><div>&lt;Redacted&gt; l=
obster!</div></div></div></div></div></div>

--000000000000616ca7063bdef917--