<div dir="auto">Yes the scenario I posted is with query cache on. </div><div dir="auto">The same scenario with query cache off is behave as expected and the session not aborted.</div><div dir="auto"><br></div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 28 Jun 2022 at 9:57 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)">> Thanks for your email.<br>
> <br>
> I am not sure why everything run as expected in that scenario if the cache<br>
> is off.<br>
><br>
> This issue happened only when the cache is on.<br>
<br>
Really? The log you posted was with the cache being on?<br>
<br>
2022-06-21 12:34:38.857: [unknown] pid 238: DETAIL: statement: "__asyncpg_stmt_5__", query: "select * from "group" limit 1"<br>
2022-06-21 12:34:38.858: [unknown] pid 238: FATAL: Backend throw an error message<br>
2022-06-21 12:34:38.858: [unknown] pid 238: DETAIL: Exiting current session because of an error from backend<br>
2022-06-21 12:34:38.858: [unknown] pid 238: HINT: BACKEND Error: "current transaction is aborted, commands ignored until end of transaction block"<br>
2022-06-21 12:34:38.858: [unknown] pid 238: CONTEXT: while searching system catalog, When relcache is missed<br>
2022-06-21 12:34:38.859: main pid 1: LOG: child process with pid: 238 exits with status 256<br>
2022-06-21 12:34:38.859: main pid 1: LOG: fork a new child process with pid: 270<br>
<br>
> And from my understanding the only difference between these scenarios is<br>
> only the catalog queries.<br>
> <br>
> In both cases the extended queries working the same and got the same error<br>
> in the transaction about the email_unique. But when the cache on the<br>
> session aborted and when the cache off it’s not. Any thoughts?<br>
<br>
My scenario brings session abort even without query cache.<br>
<br>
> On Tue, 28 Jun 2022 at 7:33 Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp" target="_blank">ishii@sraoss.co.jp</a>> wrote:<br>
> <br>
>> It turned out that flush message is irrevant. Here is a scenraio file<br>
>> for pgproto to raise such that error.<br>
>><br>
>> 'Q' "DROP TABLE IF EXISTS t1 "<br>
>> 'Y'<br>
>> 'Q' "CREATE TABLE t1(i int primary key)"<br>
>> 'Y'<br>
>> 'Q' "INSERT INTO t1 VALUES(1)"<br>
>> 'Y'<br>
>> 'Q' "BEGIN"<br>
>> 'Y'<br>
>> 'P' "" "INSERT INTO t1 VALUES(1)" 0<br>
>> 'B' "" "" 0 0 0<br>
>> 'E' "" 0<br>
>> 'Q' "SELECT count(*) from pg_class" 0<br>
>> 'P' "" "END" 0<br>
>> 'B' "" "" 0 0 0<br>
>> 'E' "" 0<br>
>> 'S'<br>
>> 'Y'<br>
>> 'X'<br>
>><br>
>> And the result is here:<br>
>><br>
>> FE=> Query (query="DROP TABLE IF EXISTS t1 ")<br>
>> <= BE CommandComplete(DROP TABLE)<br>
>> <= BE ReadyForQuery(I)<br>
>> FE=> Query (query="CREATE TABLE t1(i int primary key)")<br>
>> <= BE CommandComplete(CREATE TABLE)<br>
>> <= BE ReadyForQuery(I)<br>
>> FE=> Query (query="INSERT INTO t1 VALUES(1)")<br>
>> <= BE CommandComplete(INSERT 0 1)<br>
>> <= BE ReadyForQuery(I)<br>
>> FE=> Query (query="BEGIN")<br>
>> <= BE CommandComplete(BEGIN)<br>
>> <= BE ReadyForQuery(T)<br>
>> FE=> Parse(stmt="", query="INSERT INTO t1 VALUES(1)")<br>
>> FE=> Bind(stmt="", portal="")<br>
>> FE=> Execute(portal="")<br>
>> FE=> Query (query="SELECT count(*) from pg_class")<br>
>> FE=> Parse(stmt="", query="END")<br>
>> FE=> Bind(stmt="", portal="")<br>
>> FE=> Execute(portal="")<br>
>> FE=> Sync<br>
>> <= BE ErrorResponse(S FATAL C XX000 M Backend throw an error message D<br>
>> Exiting current session because of an error from backend H BACKEND Error:<br>
>> "duplicate key value violates unique constraint "t1_pkey"" F<br>
>> pool_process_query.c L 2130 )<br>
>> read_it: EOF detected (session aborted).<br>
>><br>
>> Suppose an extended query causes an error ("duplicate key value<br>
>> violates unique constraint "t1_pkey").<br>
>><br>
>> INSERT INTO t1 VALUES(1);<br>
>><br>
>> At the parse/describe/bind phase, this is fine as long as the table t1<br>
>> exists. However at the execute phase this could fail, for example<br>
>> because of duplicate key violation error. If we are in an explicit<br>
>> transaction, there's no way to know such an error occurred and the<br>
>> transaction is in abort state until sync message is issued because the<br>
>> sync message forces backend to issue a "ready for query" message,<br>
>> which comprises the transaction state information (and "ready for<br>
>> query" is the only message which returns the transaction state). If<br>
>> the transaction state is "abort", no query will be accepted by<br>
>> backend. Thus, if client sends a query after the transaction is in<br>
>> abort status, the query always fails. Unfortunately pgpool needs to<br>
>> issue such that quries to inspect PostgreSQL's system catalogs.<br>
>> Such queries will fail in this situation and pgpool has no choice other<br>
>> than raising a fatal error and disconnects to frontend (that's what<br>
>> you are seeing).<br>
>><br>
>> In simple query protocol, each statement always is followed by a<br>
>> "Ready for query" message and pgpool can know how is like the<br>
>> transaction state and the issue does not happen.<br>
>><br>
>> I think I was not able to find any solution for this. Sorry.<br>
>><br>
>> > Ok, thanks for the update.<br>
>> ><br>
>> > On Mon, 27 Jun 2022 at 3:12 Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp" target="_blank">ishii@sraoss.co.jp</a>> wrote:<br>
>> ><br>
>> >> I am investigating this issue using pgproto with the data you<br>
>> >> provided. It seems there are lots of "Flush" messages in the data,<br>
>> >> and I think the Flush message are causing troubles in pgpool. I guess<br>
>> >> it will take some time before I find a solution.<br>
>> >><br>
>> >> > Any thoughts?<br>
>> >> > On Wed, 22 Jun 2022 at 8:45 Avi Raboah <<a href="mailto:avi.raboah@gmail.com" target="_blank">avi.raboah@gmail.com</a>> wrote:<br>
>> >> ><br>
>> >> >> Yea you right<br>
>> >> >><br>
>> >> >> On Wed, 22 Jun 2022 at 8:45 Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp" target="_blank">ishii@sraoss.co.jp</a>> wrote:<br>
>> >> >><br>
>> >> >>> The default for backend_clustering_mode varies depending on the<br>
>> pgpool<br>
>> >> >>> versions. Can I assume you are using 4.3?<br>
>> >> >>><br>
>> >> >>> > All the configurations I didn’t provided are using the default.<br>
>> >> >>> ><br>
>> >> >>> > One more thing, the issue is occurring only if query cache enabled<br>
>> >> >>> ><br>
>> >> >>> > Thanks,<br>
>> >> >>> ><br>
>> >> >>> > Avi<br>
>> >> >>> ><br>
>> >> >>> > On Wed, 22 Jun 2022 at 4:10 Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp" target="_blank">ishii@sraoss.co.jp</a>><br>
>> wrote:<br>
>> >> >>> ><br>
>> >> >>> >> What is backend_clustering_mode?<br>
>> >> >>> >><br>
>> >> >>> >> > Pgpool.conf-<br>
>> >> >>> >> ><br>
>> >> >>> >> > listen_addresses = '*'<br>
>> >> >>> >> ><br>
>> >> >>> >> > port = '9999'<br>
>> >> >>> >> ><br>
>> >> >>> >> > socket_dir = '/var/run/pgpool'<br>
>> >> >>> >> ><br>
>> >> >>> >> > pcp_socket_dir = '/var/run/pgpool'<br>
>> >> >>> >> ><br>
>> >> >>> >> > wd_ipc_socket_dir = '/var/run/pgpool'<br>
>> >> >>> >> ><br>
>> >> >>> >> > pid_file_name = '/var/run/pgpool/pgpool.pid'<br>
>> >> >>> >> ><br>
>> >> >>> >> > backend_hostname0 = db_instance<br>
>> >> >>> >> ><br>
>> >> >>> >> > backend_port0 = '5432'<br>
>> >> >>> >> ><br>
>> >> >>> >> > backend_flag0 = 'ALLOW_TO_FAILOVER'<br>
>> >> >>> >> ><br>
>> >> >>> >> > backend_weight0 = '1'<br>
>> >> >>> >> ><br>
>> >> >>> >> > connection_cache = on<br>
>> >> >>> >> ><br>
>> >> >>> >> > num_init_children = 200<br>
>> >> >>> >> ><br>
>> >> >>> >> > child_life_time = 0<br>
>> >> >>> >> ><br>
>> >> >>> >> > max_pool = 4<br>
>> >> >>> >> ><br>
>> >> >>> >> > log_destination = 'stderr'<br>
>> >> >>> >> ><br>
>> >> >>> >> > log_line_prefix = '%m: %a pid %p: '<br>
>> >> >>> >> ><br>
>> >> >>> >> > log_connections = off<br>
>> >> >>> >> ><br>
>> >> >>> >> > log_disconnections = off<br>
>> >> >>> >> ><br>
>> >> >>> >> > log_statement = off<br>
>> >> >>> >> ><br>
>> >> >>> >> > log_client_messages = on<br>
>> >> >>> >> ><br>
>> >> >>> >> > client_min_messages = info<br>
>> >> >>> >> ><br>
>> >> >>> >> > log_min_messages = debug<br>
>> >> >>> >> ><br>
>> >> >>> >> > logging_collector = on<br>
>> >> >>> >> ><br>
>> >> >>> >> > log_directory = '/tmp/pgpool_logs'<br>
>> >> >>> >> ><br>
>> >> >>> >> > log_filename = 'pgpool-%Y-%m-%d_%H%M%S.log'<br>
>> >> >>> >> ><br>
>> >> >>> >> > log_file_mode = 0600<br>
>> >> >>> >> ><br>
>> >> >>> >> > log_truncate_on_rotation = off<br>
>> >> >>> >> ><br>
>> >> >>> >> > log_rotation_age = 1d<br>
>> >> >>> >> ><br>
>> >> >>> >> > log_rotation_size = 200MB<br>
>> >> >>> >> ><br>
>> >> >>> >> > sr_check_user = 'user'<br>
>> >> >>> >> ><br>
>> >> >>> >> > sr_check_password = 'password'<br>
>> >> >>> >> ><br>
>> >> >>> >> > sr_check_period = '10'<br>
>> >> >>> >> ><br>
>> >> >>> >> > memory_cache_enabled = 'on'<br>
>> >> >>> >> ><br>
>> >> >>> >> > memqcache_total_size = 64MB<br>
>> >> >>> >> ><br>
>> >> >>> >> > memqcache_max_num_cache = 1000000<br>
>> >> >>> >> ><br>
>> >> >>> >> > memqcache_maxcache = 400kB<br>
>> >> >>> >> ><br>
>> >> >>> >> > memqcache_cache_block_size = 1MB<br>
>> >> >>> >> ><br>
>> >> >>> >> > memqcache_oiddir = '/var/log/pgpool/oiddir'<br>
>> >> >>> >> ><br>
>> >> >>> >> > cache_safe_memqcache_table_list = ''<br>
>> >> >>> >> ><br>
>> >> >>> >> > cache_unsafe_memqcache_table_list = ''<br>
>> >> >>> >> ><br>
>> >> >>> >> > check_unlogged_table = on<br>
>> >> >>> >> ><br>
>> >> >>> >> > health_check_period = '10'<br>
>> >> >>> >> ><br>
>> >> >>> >> > health_check_user = 'user'<br>
>> >> >>> >> ><br>
>> >> >>> >> > failover_on_backend_error = 'off'<br>
>> >> >>> >> ><br>
>> >> >>> >> ><br>
>> >> >>> >> ><br>
>> >> >>> >> ><br>
>> >> >>> >> > On Tue, 21 Jun 2022 at 10:51 Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp" target="_blank">ishii@sraoss.co.jp</a>><br>
>> >> >>> wrote:<br>
>> >> >>> >> ><br>
>> >> >>> >> >> Please share the log with log_client_messages = on so that I<br>
>> can<br>
>> >> see<br>
>> >> >>> >> >> what your client actually is sending. Also I need<br>
>> pgpool.conf.<br>
>> >> >>> >> >><br>
>> >> >>> >> >> > We are using asyncPg module in python in order to send our<br>
>> >> >>> queries the<br>
>> >> >>> >> >> > difference between that module to psycopg is that asyncpg<br>
>> using<br>
>> >> >>> >> extended<br>
>> >> >>> >> >> > queries.<br>
>> >> >>> >> >> > And I can see that the issue is reproduced in case<br>
>> transaction<br>
>> >> >>> aborted<br>
>> >> >>> >> >> and<br>
>> >> >>> >> >> > the catalog queries are launched.<br>
>> >> >>> >> >> ><br>
>> >> >>> >> >> > I checked in the code and found that<br>
>> >> >>> check_transaction_state_and_abort<br>
>> >> >>> >> >> > happens only in simpleQuery process.<br>
>> >> >>> >> >> ><br>
>> >> >>> >> >> > Thanks,<br>
>> >> >>> >> >> ><br>
>> >> >>> >> >> > Avi<br>
>> >> >>> >> >> ><br>
>> >> >>> >> >> > On Tue, 21 Jun 2022 at 6:43 Tatsuo Ishii <<br>
>> <a href="mailto:ishii@sraoss.co.jp" target="_blank">ishii@sraoss.co.jp</a>><br>
>> >> >>> wrote:<br>
>> >> >>> >> >> ><br>
>> >> >>> >> >> >> Can you elaborate more?<br>
>> >> >>> >> >> >><br>
>> >> >>> >> >> >> I tried following case and pgpool ignores all queries from<br>
>> >> client<br>
>> >> >>> >> >> >> after a parse error occurs as expected.<br>
>> >> >>> >> >> >><br>
>> >> >>> >> >> >> pgproto -d test -p 11000 -f ../pgproto.data<br>
>> >> >>> >> >> >> FE=> Parse(stmt="", query="BEGIN")<br>
>> >> >>> >> >> >> FE=> Bind(stmt="", portal="")<br>
>> >> >>> >> >> >> FE=> Execute(portal="")<br>
>> >> >>> >> >> >> FE=> Parse(stmt="", query="INSERT INTO non_existing_table<br>
>> >> >>> values(1)")<br>
>> >> >>> >> >> >> FE=> Bind(stmt="", portal="")<br>
>> >> >>> >> >> >> FE=> Execute(portal="")<br>
>> >> >>> >> >> >> FE=> Parse(stmt="", query="END")<br>
>> >> >>> >> >> >> FE=> Bind(stmt="", portal="")<br>
>> >> >>> >> >> >> FE=> Execute(portal="")<br>
>> >> >>> >> >> >> FE=> Sync<br>
>> >> >>> >> >> >> <= BE ParseComplete<br>
>> >> >>> >> >> >> <= BE BindComplete<br>
>> >> >>> >> >> >> <= BE CommandComplete(BEGIN)<br>
>> >> >>> >> >> >> <= BE ErrorResponse(S ERROR V ERROR C 42P01 M relation<br>
>> >> >>> >> >> >> "non_existing_table" does not exist P 13 F<br>
>> parse_relation.c L<br>
>> >> >>> 1381 R<br>
>> >> >>> >> >> >> parserOpenTable )<br>
>> >> >>> >> >> >> <= BE ReadyForQuery(E)<br>
>> >> >>> >> >> >> FE=> Terminate<br>
>> >> >>> >> >> >><br>
>> >> >>> >> >> >> > Hi,<br>
>> >> >>> >> >> >> ><br>
>> >> >>> >> >> >> > After investigating the code I found that the patch you<br>
>> >> >>> provided is<br>
>> >> >>> >> >> >> fixing<br>
>> >> >>> >> >> >> > the problem only for simple query. In extended query the<br>
>> >> issue<br>
>> >> >>> >> still<br>
>> >> >>> >> >> >> exist.<br>
>> >> >>> >> >> >> ><br>
>> >> >>> >> >> >> > Do you know where is the right place to add the<br>
>> transaction<br>
>> >> >>> failure<br>
>> >> >>> >> >> >> > verification in extended query process?<br>
>> >> >>> >> >> >> > On Mon, 9 May 2022 at 16:17 Tatsuo Ishii <<br>
>> >> <a href="mailto:ishii@sraoss.co.jp" target="_blank">ishii@sraoss.co.jp</a>><br>
>> >> >>> >> wrote:<br>
>> >> >>> >> >> >> ><br>
>> >> >>> >> >> >> >> The patch (plus more fix) has been committed to master<br>
>> and<br>
>> >> 4.3<br>
>> >> >>> >> stable<br>
>> >> >>> >> >> >> >> branches.<br>
>> >> >>> >> >> >> >><br>
>> >> >>> >> >> >> >><br>
>> >> >>> >> >><br>
>> >> >>><br>
>> >> <a href="https://www.pgpool.net/pipermail/pgpool-committers/2022-May/008592.html" rel="noreferrer" target="_blank">https://www.pgpool.net/pipermail/pgpool-committers/2022-May/008592.html</a><br>
>> >> >>> >> >> >> >><br>
>> >> >>> >> >><br>
>> >> >>><br>
>> >> <a href="https://www.pgpool.net/pipermail/pgpool-committers/2022-May/008591.html" rel="noreferrer" target="_blank">https://www.pgpool.net/pipermail/pgpool-committers/2022-May/008591.html</a><br>
>> >> >>> >> >> >> >><br>
>> >> >>> >> >> >> >> The patches will appear in the next release (May 19,<br>
>> 2022).<br>
>> >> >>> >> >> >> >><br>
>> >> >>> >> >> >> >> I have not pushed to other stable branches because the<br>
>> fix<br>
>> >> is<br>
>> >> >>> not<br>
>> >> >>> >> >> >> >> small and I wanted to minimize risks.<br>
>> >> >>> >> >> >> >><br>
>> >> >>> >> >> >> >> > Thanks a lot for the patch have a great weekend<br>
>> >> >>> >> >> >> >> ><br>
>> >> >>> >> >> >> >> > On Sat, 7 May 2022 at 13:35 Tatsuo Ishii <<br>
>> >> >>> <a href="mailto:ishii@sraoss.co.jp" target="_blank">ishii@sraoss.co.jp</a>><br>
>> >> >>> >> >> wrote:<br>
>> >> >>> >> >> >> >> ><br>
>> >> >>> >> >> >> >> >> > Hi,<br>
>> >> >>> >> >> >> >> >> ><br>
>> >> >>> >> >> >> >> >> > Still thinking.<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>
>> >> >>> >> >> >> >> >> ><br>
>> >> >>> >> >> >> >> >> ><br>
>> >> >>> >> >> >> >> >> >> Hi,<br>
>> >> >>> >> >> >> >> >> >><br>
>> >> >>> >> >> >> >> >> >> Any news about this thread?<br>
>> >> >>> >> >> >> >> >> >><br>
>> >> >>> >> >> >> >> >> >> Thanks,<br>
>> >> >>> >> >> >> >> >> >> Avi.<br>
>> >> >>> >> >> >> >> >> >><br>
>> >> >>> >> >> >> >> >> >> On Mon, 25 Apr 2022 at 11:13 Avi Raboah <<br>
>> >> >>> >> <a href="mailto:avi.raboah@gmail.com" target="_blank">avi.raboah@gmail.com</a>><br>
>> >> >>> >> >> >> >> wrote:<br>
>> >> >>> >> >> >> >> >> >><br>
>> >> >>> >> >> >> >> >> >>> It will be perfect thanks a lot!<br>
>> >> >>> >> >> >> >> >> >>><br>
>> >> >>> >> >> >> >> >> >>> On Mon, 25 Apr 2022 at 10:47 Tatsuo Ishii <<br>
>> >> >>> >> <a href="mailto:ishii@sraoss.co.jp" target="_blank">ishii@sraoss.co.jp</a><br>
>> >> >>> >> >> ><br>
>> >> >>> >> >> >> >> wrote:<br>
>> >> >>> >> >> >> >> >> >>><br>
>> >> >>> >> >> >> >> >> >>>> > No, it doesn't.<br>
>> >> >>> >> >> >> >> >> >>>> > In that case when you make the select<br>
>> statement,<br>
>> >> >>> piggy<br>
>> >> >>> >> >> >> internal<br>
>> >> >>> >> >> >> >> >> queries<br>
>> >> >>> >> >> >> >> >> >>>> > failed and the session rebooted<br>
>> >> >>> >> >> >> >> >> >>>><br>
>> >> >>> >> >> >> >> >> >>>> I see it now.<br>
>> >> >>> >> >> >> >> >> >>>><br>
>> >> >>> >> >> >> >> >> >>>> test=# begin;<br>
>> >> >>> >> >> >> >> >> >>>> BEGIN<br>
>> >> >>> >> >> >> >> >> >>>> test=*# insert into ttt values(1);<br>
>> >> >>> >> >> >> >> >> >>>> ERROR: relation "ttt" does not exist<br>
>> >> >>> >> >> >> >> >> >>>> LINE 1: insert into ttt values(1);<br>
>> >> >>> >> >> >> >> >> >>>> ^<br>
>> >> >>> >> >> >> >> >> >>>> test=!# select * from t1;<br>
>> >> >>> >> >> >> >> >> >>>> FATAL: Backend throw an error message<br>
>> >> >>> >> >> >> >> >> >>>> DETAIL: Exiting current session because of an<br>
>> >> error<br>
>> >> >>> from<br>
>> >> >>> >> >> >> backend<br>
>> >> >>> >> >> >> >> >> >>>> HINT: BACKEND Error: "current transaction is<br>
>> >> aborted,<br>
>> >> >>> >> >> commands<br>
>> >> >>> >> >> >> >> >> ignored<br>
>> >> >>> >> >> >> >> >> >>>> until end of transaction block"<br>
>> >> >>> >> >> >> >> >> >>>> server closed the connection unexpectedly<br>
>> >> >>> >> >> >> >> >> >>>> This probably means the server<br>
>> terminated<br>
>> >> >>> >> abnormally<br>
>> >> >>> >> >> >> >> >> >>>> before or while processing the request.<br>
>> >> >>> >> >> >> >> >> >>>> The connection to the server was lost.<br>
>> Attempting<br>
>> >> >>> reset:<br>
>> >> >>> >> >> >> Succeeded.<br>
>> >> >>> >> >> >> >> >> >>>><br>
>> >> >>> >> >> >> >> >> >>>> I think pgpool could remember that current<br>
>> >> >>> transaction is<br>
>> >> >>> >> in<br>
>> >> >>> >> >> >> abort<br>
>> >> >>> >> >> >> >> >> >>>> status and does not issue the piggyback query<br>
>> when<br>
>> >> the<br>
>> >> >>> >> selec<br>
>> >> >>> >> >> is<br>
>> >> >>> >> >> >> >> >> >>>> issued. Let me see what we can do for this.<br>
>> >> >>> >> >> >> >> >><br>
>> >> >>> >> >> >> >> >> I have come up with a patch. In this patch pgpool<br>
>> >> checks if<br>
>> >> >>> >> >> current<br>
>> >> >>> >> >> >> >> >> transaction is in abort status. If so, it does not<br>
>> >> accept<br>
>> >> >>> new<br>
>> >> >>> >> >> query<br>
>> >> >>> >> >> >> at<br>
>> >> >>> >> >> >> >> >> all and just reply back frontend with the message:<br>
>> >> >>> >> >> >> >> >><br>
>> >> >>> >> >> >> >> >> "current transaction is aborted, commands ignored<br>
>> until<br>
>> >> >>> end of<br>
>> >> >>> >> >> >> >> transaction<br>
>> >> >>> >> >> >> >> >> block"<br>
>> >> >>> >> >> >> >> >><br>
>> >> >>> >> >> >> >> >> until commit or abort command is sent from frontend.<br>
>> >> After<br>
>> >> >>> >> >> applying<br>
>> >> >>> >> >> >> >> >> the patch the example session above looks like this:<br>
>> >> >>> >> >> >> >> >><br>
>> >> >>> >> >> >> >> >> test=# begin;<br>
>> >> >>> >> >> >> >> >> BEGIN<br>
>> >> >>> >> >> >> >> >> test=*# insert into ttt values(1);<br>
>> >> >>> >> >> >> >> >> ERROR: relation "ttt" does not exist<br>
>> >> >>> >> >> >> >> >> LINE 1: insert into ttt values(1);<br>
>> >> >>> >> >> >> >> >> ^<br>
>> >> >>> >> >> >> >> >> test=!# select * from t1;<br>
>> >> >>> >> >> >> >> >> ERROR: current transaction is aborted, commands<br>
>> ignored<br>
>> >> >>> until<br>
>> >> >>> >> >> end of<br>
>> >> >>> >> >> >> >> >> transaction block<br>
>> >> >>> >> >> >> >> >><br>
>> >> >>> >> >> >> >> >> The patch was tested in master branch, but I believe<br>
>> it<br>
>> >> >>> can be<br>
>> >> >>> >> >> >> >> >> applied to 4.3 stable branch as well.<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>
>> >> >>> >> >> >> >> >><br>
>> >> >>> >> >> >> >><br>
>> >> >>> >> >> >><br>
>> >> >>> >> >><br>
>> >> >>> >><br>
>> >> >>><br>
>> >> >><br>
>> >><br>
>><br>
</blockquote></div></div>