MIME-Version: 1.0
References: <CAD=40Z3Rvbx46SxYBBdLvgSObXCP+Firszz++rDTXmGX795D2Q@mail.gmail.com>
 <6c498f0e-64f9-449a-9b90-5cd72d00e2ef@aklaver.com> <CAD=40Z1wJ7mBej9=Yqfo_1m-eOV61E=s6yDjZSaTBESbGunBUA@mail.gmail.com>
 <2a7d96ac-83a7-4ddc-a3ce-9c637f2c1c76@aklaver.com> <CAD=40Z3prwhLAedetocCu3jFvHSBP44V6O9d6CXjvzLTw7eOUQ@mail.gmail.com>
In-Reply-To: <CAD=40Z3prwhLAedetocCu3jFvHSBP44V6O9d6CXjvzLTw7eOUQ@mail.gmail.com>
From: Ron Johnson <ronljohnsonjr@gmail.com>
Date: Sun, 24 Nov 2024 11:57:08 -0500
Message-ID: <CANzqJaACBw1=jCAxGwSeu7dh4UfD2KePcNqSOC3=WwzXrg0skQ@mail.gmail.com>
Subject: Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting
 Up Streaming Replication
To: pgsql-general <pgsql-general@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000004f76b50627ab8262"
Archived-At: <https://www.postgresql.org/message-id/CANzqJaACBw1%3DjCAxGwSeu7dh4UfD2KePcNqSOC3%3DWwzXrg0skQ%40mail.gmail.com>
Precedence: bulk

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

On Sun, Nov 24, 2024 at 11:52=E2=80=AFAM Subhash Udata <subhashudata@gmail.=
com>
wrote:

> I understand your point and appreciate the clarification.
>
> I have reviewed the references and now have a better understanding of the
> minor upgrade process.
>
> However, my concern lies in the fact that we are working with production
> servers, where downtime is not acceptable.
>
> Additionally, if a failover occurs due to a network issue or any other
> disaster, setting up replication again requires running the pg_basebackup
> command. For large databases, this process becomes a significant challeng=
e,
> as running pg_basebackup for the entire cluster can be time-consuming and
> resource-intensive.
>

A comment and a question:
1) pg_basebackup runs just fine from cron.  Thus, "time-consuming" (which
you described as 2-3 hours) isn't that critical.
2) What do you mean by resource-intensive?  If it means network bandwidth,
then read the pg_basebackup man page.

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

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

<div dir=3D"ltr"><div dir=3D"ltr">On Sun, Nov 24, 2024 at 11:52=E2=80=AFAM =
Subhash Udata &lt;<a href=3D"mailto:subhashudata@gmail.com">subhashudata@gm=
ail.com</a>&gt; wrote:</div><div class=3D"gmail_quote"><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><p>I unders=
tand your point and appreciate the clarification.</p><p>I have reviewed the=
 references and now have a better understanding of the minor upgrade proces=
s.</p><p>However, my concern lies in the fact that we are working with prod=
uction servers, where downtime is not acceptable.</p><p>Additionally, if a =
failover occurs due to a network issue or any other disaster, setting up re=
plication again requires running the <code>pg_basebackup</code> command. Fo=
r large databases, this process becomes a significant challenge, as running=
 <code>pg_basebackup</code> for the entire cluster can be time-consuming an=
d resource-intensive.</p></div></div></blockquote><div><br></div><div>A com=
ment and a question:</div><div></div></div><div>1) pg_basebackup runs just =
fine from cron.=C2=A0 Thus, &quot;time-consuming&quot; (which you described=
 as 2-3 hours) isn&#39;t that critical.</div><div>2) What do you mean by re=
source-intensive?=C2=A0 If it means network bandwidth, then read the pg_bas=
ebackup man page.</div><div><br></div><span class=3D"gmail_signature_prefix=
">-- </span><br><div dir=3D"ltr" class=3D"gmail_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; lobster!</div></div></div></di=
v></div></div>

--0000000000004f76b50627ab8262--