MIME-Version: 1.0
References: <Zw8MRH2ks_BgLTa-@paquier.xyz>
 <Zw+RPPRDK+L2W480@ip-10-97-1-34.eu-west-3.compute.internal>
 <ZxCRku2jk8Jz0sTU@paquier.xyz> <ZzWs6_pKr8DgEAvs@paquier.xyz>
 <ZzXL7WkzGyhxJljW@ip-10-97-1-34.eu-west-3.compute.internal>
 <ZzbR5Eu66lP9rt50@paquier.xyz>
 <CAN4RuQvYth942J2+FcLmJKgdpq6fE5eqyFvb_PuskxF2eL=Wzg@mail.gmail.com>
 <aJPiwtnsuh9yfFnz@paquier.xyz>
 <CAN4RuQt_Sr9h2NG0-fr7XSmU=DeHkzTeysCuOAWhWrkuhw8Puw@mail.gmail.com>
 <CAN4RuQs6ht4T7ph8NbxHZ+NmDmTrvczAxpyZmcqk+74tzsciuw@mail.gmail.com>
 <aMIJozPEP5OLI3Yj@paquier.xyz>
In-Reply-To: <aMIJozPEP5OLI3Yj@paquier.xyz>
From: Kouber Saparev <kouber@gmail.com>
Date: Thu, 11 Sep 2025 16:35:01 +0300
Message-ID: 
 <CAN4RuQv3OTJ1Owqn2U+7ZbvL-N-nZYAUjF_NG8o12ayFN-=0GQ@mail.gmail.com>
Subject: Re: BF mamba failure
To: Michael Paquier <michael@paquier.xyz>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
 pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000b91902063e869bf9"
Archived-At: 
 <https://www.postgresql.org/message-id/CAN4RuQv3OTJ1Owqn2U%2B7ZbvL-N-nZYAUjF_NG8o12ayFN-%3D0GQ%40mail.gmail.com>
Precedence: bulk

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

=D0=9D=D0=B0 =D1=87=D1=82, 11.09.2025=E2=80=AF=D0=B3. =D0=B2 2:28 Michael P=
aquier <michael@paquier.xyz> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:

> As a start, are these failures only in the startup process?  Has the
> startup process reached a consistent state when the problem happens
> because the replay code is too eager at removing the stats entries?
> Has it not reached a consistent state.  These could be useful hints to
> extract a reproducible test case, looking for common patterns.
>

The pattern is the same, although I am not 100% sure that the same replica
is having this - it is a cascaded streaming replica, i.e. a replica of
another replica. Once we had this in October 2024, with version 15.4, then
in August 2025 with 17.3, and now in September again (17.3). The database
is working for month(s) perfectly fine in a heavy production workload (lots
of WALs etc.), and then all of a sudden it shuts down.

Thanks for the feedback, and let me know if I could provide any additional
info.

--
Kouber

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

<div dir=3D"ltr"><div>=D0=9D=D0=B0 =D1=87=D1=82, 11.09.2025=E2=80=AF=D0=B3.=
 =D0=B2 2:28 Michael Paquier &lt;<a href=3D"mailto:michael@paquier.xyz">mic=
hael@paquier.xyz</a>&gt; =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:</div><div cl=
ass=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">As a start, are these failures only in the startup process=
?=C2=A0 Has the<br>
startup process reached a consistent state when the problem happens<br>
because the replay code is too eager at removing the stats entries?<br>
Has it not reached a consistent state.=C2=A0 These could be useful hints to=
<br>
extract a reproducible test case, looking for common patterns.<br></blockqu=
ote><div><br>The pattern is the same, although I am not 100% sure that the =
same replica is having this - it is a cascaded streaming replica, i.e. a re=
plica of another replica. Once we had this in October 2024, with version 15=
.4, then in August 2025 with 17.3, and now in September again (17.3). The d=
atabase is working for month(s) perfectly fine in=C2=A0a heavy production w=
orkload (lots of WALs etc.), and then all of a sudden it shuts down.<br><br=
>Thanks for the feedback, and let me know if I could provide any additional=
 info.=C2=A0<br><br>--<br>Kouber</div></div></div>

--000000000000b91902063e869bf9--