Feedback-ID: i0c21471d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-300-gdee1775a43-fm-20240315.001-gdee1775a
MIME-Version: 1.0
Message-Id: <60a297be-c0c7-4468-88d2-81ba560e1f9f@app.fastmail.com>
In-Reply-To: 
 <CALDaNm3VMOi0GugGvhk3motghaFRKSWMCSE2t3YX1e+MttToxg@mail.gmail.com>
References: <9a9c7e65-c47b-4400-a63e-ac6169c0860e@app.fastmail.com>
 <2edde173-5ff9-45fd-b881-cd04eb13049f@app.fastmail.com>
 <TYCPR01MB120777DED2C72F897EF6E57D1F54E2@TYCPR01MB12077.jpnprd01.prod.outlook.com>
 <TYCPR01MB12077646F91423005D657FF20F54D2@TYCPR01MB12077.jpnprd01.prod.outlook.com>
 <2231a04b-f2d4-4a4e-b5cd-56be8b002427@app.fastmail.com>
 <TYCPR01MB12077756323B79042F29DDAEDF54C2@TYCPR01MB12077.jpnprd01.prod.outlook.com>
 <TYCPR01MB12077A8421685E5515DE408EEF5512@TYCPR01MB12077.jpnprd01.prod.outlook.com>
 <CALDaNm2ev8_r4N5Sfa2GjzuzZNz17L0nsX_ZqfcarmS5oa5Szw@mail.gmail.com>
 <TYCPR01MB12077CD333376B53F9CAE7AC0F5562@TYCPR01MB12077.jpnprd01.prod.outlook.com>
 <e390e35e-508e-4eb8-92e4-e6b066407a41@app.fastmail.com>
 <TYCPR01MB12077121263EFF7680486B635F5212@TYCPR01MB12077.jpnprd01.prod.outlook.com>
 <40595e73-c7e1-463a-b8be-49792e870007@app.fastmail.com>
 <6423dfeb-a729-45d3-b71e-7bf1b3adb0c9@enterprisedb.com>
 <TYCPR01MB12077DE77454D68E959E85E35F5272@TYCPR01MB12077.jpnprd01.prod.outlook.com>
 <8d52c226-7e34-44f7-a919-759bf8d81541@enterprisedb.com>
 <CALDaNm3Fg4zJ9RxnQPSW7FFqy_K605urNM_B3zAaO84Dr7_zcA@mail.gmail.com>
 <TYCPR01MB12077871481317F4E7D48FEF1F5242@TYCPR01MB12077.jpnprd01.prod.outlook.com>
 <CALDaNm3VMOi0GugGvhk3motghaFRKSWMCSE2t3YX1e+MttToxg@mail.gmail.com>
Date: Sat, 16 Mar 2024 12:46:07 -0300
From: "Euler Taveira" <euler@eulerto.com>
To: "vignesh C" <vignesh21@gmail.com>,
 "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>
Cc: 
 "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
 "Tomas Vondra" <tomas.vondra@enterprisedb.com>,
 "Michael Paquier" <michael@paquier.xyz>,
 "Peter Eisentraut" <peter@eisentraut.org>,
 "Andres Freund" <andres@anarazel.de>,
 "Ashutosh Bapat" <ashutosh.bapat.oss@gmail.com>,
 "Amit Kapila" <amit.kapila16@gmail.com>,
 "Shlok Kyal" <shlok.kyal.oss@gmail.com>,
 =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabriziomello@gmail.com>
Subject: Re: speed up a logical replica setup
Content-Type: multipart/alternative;
 boundary=e4fdbbeb03b74adda6a776413cfb26fc
Archived-At: <https://www.postgresql.org/message-id/60a297be-c0c7-4468-88d2-81ba560e1f9f%40app.fastmail.com>
Precedence: bulk

--e4fdbbeb03b74adda6a776413cfb26fc
Content-Type: text/plain

On Sat, Mar 16, 2024, at 10:31 AM, vignesh C wrote:
> I was able to reproduce this random failure and found the following reason:
> The Minimum recovery ending location 0/5000000 was more than the
> recovery_target_lsn specified is "0/4001198". In few random cases the
> standby applies a few more WAL records after the replication slot is
> created; this leads to minimum recovery ending location being greater
> than the recovery_target_lsn because of which the server will fail
> with:
> FATAL:  requested recovery stop point is before consistent recovery point

Thanks for checking. I proposed an alternative patch for it [1]. Can you check
it?

[1] https://www.postgresql.org/message-id/34637e7f-0330-420d-8f45-1d022962d2fe%40app.fastmail.com


--
Euler Taveira
EDB   https://www.enterprisedb.com/

--e4fdbbeb03b74adda6a776413cfb26fc
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Sat, Mar 16,=
 2024, at 10:31 AM, vignesh C wrote:<br></div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>I was able to reproduce this random failure an=
d found the following reason:<br></div><div>The Minimum recovery ending =
location 0/5000000 was more than the<br></div><div>recovery_target_lsn s=
pecified is "0/4001198". In few random cases the<br></div><div>standby a=
pplies a few more WAL records after the replication slot is<br></div><di=
v>created; this leads to minimum recovery ending location being greater<=
br></div><div>than the recovery_target_lsn because of which the server w=
ill fail<br></div><div>with:<br></div><div>FATAL:&nbsp; requested recove=
ry stop point is before consistent recovery point<br></div></blockquote>=
<div><br></div><div>Thanks for checking. I proposed an alternative patch=
 for it [1]. Can you check<br></div><div>it?<br></div><div><br></div><di=
v>[1]&nbsp;<a href=3D"https://www.postgresql.org/message-id/34637e7f-033=
0-420d-8f45-1d022962d2fe%40app.fastmail.com">https://www.postgresql.org/=
message-id/34637e7f-0330-420d-8f45-1d022962d2fe%40app.fastmail.com</a><b=
r></div><div><br></div><div><br></div><div id=3D"sig112409080"><div clas=
s=3D"signature">--<br></div><div class=3D"signature">Euler Taveira<br></=
div><div class=3D"signature">EDB&nbsp;&nbsp; <a href=3D"https://www.ente=
rprisedb.com/">https://www.enterprisedb.com/</a><br></div></div><div><br=
></div></body></html>
--e4fdbbeb03b74adda6a776413cfb26fc--