User-Agent: Cyrus-JMAP/3.7.0-alpha0-591-gfe6c3a2700-fm-20220427.001-gfe6c3a27
Mime-Version: 1.0
Message-Id: <78d4b56b-f6a5-4260-90a6-9943e0e88ce6@www.fastmail.com>
In-Reply-To: 
 <CAA4eK1LoVa8rJ0nD3kyDMEc4ZmGWjjwDk+twSiz81ffMua5iXQ@mail.gmail.com>
References: 
 <OS3PR01MB6275982DA7BBA25DE88F6E839EF59@OS3PR01MB6275.jpnprd01.prod.outlook.com>
 <CAD21AoDWs2Ru9Zc_jzjrA4k4JUtUDN2_9GktbuAzwHwdJY2myg@mail.gmail.com>
 <OS0PR01MB5716F30A9F73742BC8EA95A594FD9@OS0PR01MB5716.jpnprd01.prod.outlook.com>
 <CAD21AoD7P9UU4nMgrotD_7LDbzpTpKugpwbjq5VUAbriqzVOSg@mail.gmail.com>
 <CAA4eK1JBT_ZKY5xSG_cwD7EOb26GrK2_CS1YPBgxE7rc69Y3jg@mail.gmail.com>
 <CAD21AoB4km=SgT0DAJOoKYicVNqvWZMtuQ7D9d0RFq20NK_EEw@mail.gmail.com>
 <CAA4eK1JuhAuG-SzxCXi5YMhpKvGT_-boJT61e7Z14qfp6AwG6g@mail.gmail.com>
 <CAD21AoAB_K2ZA_=Ja4COLM5-dJb2O_7nr1q1TmapSWSxdnh5KA@mail.gmail.com>
 <OS3PR01MB62754AA446A2FB5B72816C529EC59@OS3PR01MB6275.jpnprd01.prod.outlook.com>
 <CAA4eK1LoVa8rJ0nD3kyDMEc4ZmGWjjwDk+twSiz81ffMua5iXQ@mail.gmail.com>
Date: Mon, 09 May 2022 10:30:52 -0300
From: "Euler Taveira" <euler@eulerto.com>
To: "Amit Kapila" <amit.kapila16@gmail.com>,
 "wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>
Cc: "Masahiko Sawada" <sawada.mshk@gmail.com>,
 "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>,
 "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>,
 "Peter Smith" <smithpb2250@gmail.com>,
 "Fabrice Chapuis" <fabrice636861@gmail.com>,
 "Simon Riggs" <simon.riggs@enterprisedb.com>,
 "Petr Jelinek" <petr.jelinek@enterprisedb.com>,
 "tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>,
 "PostgreSQL Hackers" <pgsql-hackers@lists.postgresql.org>,
 "Ajin Cherian" <itsajin@gmail.com>
Subject: Re: Logical replication timeout problem
Content-Type: multipart/alternative;
 boundary=14c4027ab2b044eda38d4c5997312c37
Archived-At: 
 <https://www.postgresql.org/message-id/78d4b56b-f6a5-4260-90a6-9943e0e88ce6%40www.fastmail.com>
Precedence: bulk

--14c4027ab2b044eda38d4c5997312c37
Content-Type: text/plain

On Mon, May 9, 2022, at 3:47 AM, Amit Kapila wrote:
> Thanks. The patch LGTM. I'll push and back-patch this after the
> current minor release is done unless there are more comments related
> to this work.
Looks sane to me. (I only tested the HEAD version)

+   bool        end_xact = ctx->end_xact;

Do you really need a new variable here? It has the same name and the new one
isn't changed during the execution.

Does this issue deserve a test? A small wal_receiver_timeout. Although, I'm not
sure how stable the test will be.


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

--14c4027ab2b044eda38d4c5997312c37
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 Mon, May 9, =
2022, at 3:47 AM, Amit Kapila wrote:<br></div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>Thanks. The patch LGTM. I'll push and back-pat=
ch this after the<br></div><div>current minor release is done unless the=
re are more comments related<br></div><div>to this work.<br></div></bloc=
kquote><div>Looks sane to me. (I only tested the HEAD version)<br></div>=
<div><br></div><div>+&nbsp;&nbsp; bool&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; end_xact =3D ctx-&gt;end_xact;<br></div><div><br></div><div>Do =
you really need a new variable here? It has the same name and the new on=
e<br></div><div>isn't changed during the execution.<br></div><div><br></=
div><div>Does this issue deserve a test? A small wal_receiver_timeout. A=
lthough, I'm not<br></div><div>sure how stable the test will be.<br></di=
v><div><br></div><div><br></div><div id=3D"sig112409080"><div class=3D"s=
ignature">--<br></div><div class=3D"signature">Euler Taveira<br></div><d=
iv class=3D"signature">EDB&nbsp;&nbsp; <a href=3D"https://www.enterprise=
db.com/">https://www.enterprisedb.com/</a><br></div></div><div><br></div=
></body></html>
--14c4027ab2b044eda38d4c5997312c37--