MIME-Version: 1.0
In-Reply-To: <CAGbX52ENsSHKoTyu5+XfN1o1bZ2w2CJaE1oQnxcm=fj2SyoZXg@mail.gmail.com>
References: <CAGbX52Fg2jxqGVZzeQ_QcHSZ8fgDjnVZUJy5NUb5-PAf8fvxkw@mail.gmail.com>
 <52afa4c9-7393-4265-88bb-6393f1b0fb03@aklaver.com> <CAGbX52EyjjOQJUjA0m4+0azs_yH1by63p6hhJg7Y66=VCCqzpA@mail.gmail.com>
 <45e8c44b-2506-41b5-b999-5fdc42472644@aklaver.com> <CAGbX52ENsSHKoTyu5+XfN1o1bZ2w2CJaE1oQnxcm=fj2SyoZXg@mail.gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
Date: Mon, 21 Oct 2024 15:34:58 -0700
Message-ID: <CAKFQuwYCwp-sR=p6oCysRTLyiX4c_kj6DOtHxFqHS3Pg05u1dg@mail.gmail.com>
Subject: Re: Basebackup fails without useful error message
To: Koen De Groote <kdg.dev@gmail.com>
Cc: Adrian Klaver <adrian.klaver@aklaver.com>, 
	PostgreSQL General <pgsql-general@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="00000000000047be5c0625044356"
Archived-At: <https://www.postgresql.org/message-id/CAKFQuwYCwp-sR%3Dp6oCysRTLyiX4c_kj6DOtHxFqHS3Pg05u1dg%40mail.gmail.com>
Precedence: bulk

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

On Sunday, October 20, 2024, Koen De Groote <kdg.dev@gmail.com> wrote:
>
>
> I'm going to be testing this. If someone could confirm that this is how
> writing WAL files works, that being: that it is only considered "done" wh=
en
> the archive_command is done, that would be great.
>

The archiving of WAL files by the primary does not involve a replication
connection of any sort and thus the =E2=80=9CWAL sender=E2=80=9D settings a=
re not relevant
to it; or, here, whether or not you are archiving your WAL is immaterial
since you are streaming it as it gets produced.

If you are streaming WAL it seems highly unusual that you=E2=80=99d end up =
in a
situation where the connection goes idle long enough that it gets killed,
especially if the backup is still happening.  I=E2=80=99d probably go with
performing the backup under a disabled (or extremely large?) timeout though
and move on to other things.

That isn=E2=80=99t to say I fully understand what actually is happening her=
e=E2=80=A6

David J.

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

On Sunday, October 20, 2024, Koen De Groote &lt;<a href=3D"mailto:kdg.dev@g=
mail.com">kdg.dev@gmail.com</a>&gt; wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div><div><br></div><div>I&#39;m going to be testing this. I=
f someone could confirm that this is how writing WAL files works, that bein=
g: that it is only considered &quot;done&quot; when the archive_command is =
done, that would be great.</div></div></div></blockquote><div><br></div><di=
v>The archiving of WAL files by the primary does not involve a replication =
connection of any sort and thus the =E2=80=9CWAL sender=E2=80=9D settings a=
re not relevant to it; or, here, whether or not you are archiving your WAL =
is immaterial since you are streaming it as it gets produced.</div><div><br=
></div><div>If you are streaming WAL it seems highly unusual that you=E2=80=
=99d end up in a situation where the connection goes idle long enough that =
it gets killed, especially if the backup is still happening.=C2=A0 I=E2=80=
=99d probably go with performing the backup under a disabled (or extremely =
large?) timeout though and move on to other things.</div><div><br></div><di=
v>That isn=E2=80=99t to say I fully understand what actually is happening h=
ere=E2=80=A6</div><div><br></div><div>David J.</div><div><br></div>

--00000000000047be5c0625044356--