<div dir="auto">Thanks for the explanation and fast response.</div><div dir="auto"><br></div><div dir="auto">You mentioned the piggy internal queries, and I am trying to understand if what I saw is the right behaving.</div><div dir="auto"><br></div><div dir="auto">I open a transaction, and my second statement was an Insert statement which was failed. In that case any other statements should be ignored until rollback. But after the Insert statement I did a select statement which triggers the piggy internal queries. In that case the first internal query was failed and because of that the connection was rebooted.</div><div dir="auto"><br></div><div dir="auto">In that case this is fine ? Or not? Why piggy behave different  in that scenario where the internal query failed due to an earlier transaction error? </div><div dir="auto"><br></div><div dir="auto">Thanks 🙏 </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 25 Apr 2022 at 3:26 Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp">ishii@sraoss.co.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">> Hi,<br>
> <br>
> I saw in the code the fixing for the hung query in pg_stat_activity. The<br>
> issue was fixed by killing the child process and restarting the session<br>
> instead of sending a sync message.<br>
> Do the fix is still relevant or has this issue already fixed by Postgres<br>
> team?<br>
<br>
No.<br>
<br>
I assume you are seeing the code in do_query(). Actually the code is<br>
not specific to pg_stat_activity at all.<br>
<br>
When client sends a query which includes reference to tables or<br>
functions, pgpool dynamically sends a system catalog lookup query to<br>
PostgreSQL. do_query() is the workhorse for the work.  do_query()<br>
piggybacks the query on the existing connection so that pgpool does<br>
not need to open a new connection to PostgreSQL (it would be slow and<br>
waste of resource). The query result from PostgreSQL is not returned<br>
to the client, rather is consumed by pgpool to analyze the result for<br>
further processing (for example, determining whether the table in<br>
question is a temporary table or not).<br>
<br>
Currently pgpool discards the session to client if the system catalog<br>
lookup query fails. The reason is, if pgpool does not do that, the<br>
recovery from the failure would be too complex and fragile. For<br>
example, if there are multiple PostgreSQL servers, pgpool creates<br>
connections to each PostgreSQL. do_query() uses one of the<br>
connections. Suppose by the time when do_query() gets called, a<br>
transaction was open and do_query() fails. If pgpool tries to recover<br>
the error, it needs to send back an error to the client but also needs<br>
to deal with other PostgreSQL servers. For example they need to close<br>
the transaction. Just sending sync message does not solve the problem.<br>
<br>
Also if the system catalog lookup query fails, then there's something<br>
going wrong in the PostgreSQL server, which should not happen<br>
frequently. So I think making do_query() more complex to deal with the<br>
rare case problems is not worth the trouble.<br>
<br>
> In case I don't want to use this fix what is the best way to ignore the<br>
> session booting?<br>
<br>
There's no way to avoid the session booting.<br>
<br>
Best reagards,<br>
--<br>
Tatsuo Ishii<br>
SRA OSS, Inc. Japan<br>
English: <a href="http://www.sraoss.co.jp/index_en.php" rel="noreferrer" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
Japanese:<a href="http://www.sraoss.co.jp" rel="noreferrer" target="_blank">http://www.sraoss.co.jp</a><br>
</blockquote></div></div>