[pgpool-hackers: 4159] Re: [pgpool-committers: 8591] pgpool: Fix not to abort session while in failed transaction.

[Tatsuo Ishii]

I have pusehd following fix to master and 4.3 stable branches.  I
thought the fix was too invasive to back port to the rest of stable
branches. But I am changing my mind because if we do not have the fix
in those branches, subsequent maintenance effort will be harder.  Let
me see how the buildfarm responses to the fix. If there's no problem,
probably we should back port the fix to 4.2 or older branches.

Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

From: Tatsuo Ishii <ishii at sraoss.co.jp>
Subject: [pgpool-committers: 8591] pgpool: Fix not to abort session while in failed transaction.
Date: Mon, 09 May 2022 13:08:46 +0000
Message-ID: <E1no382-00078P-AU at gothos.postgresql.org>

> Fix not to abort session while in failed transaction.
> 
> When an explicit transaction fails, subsequent commands should be
> ignored until commit or rollback command comes in. However pgpool
> sometimes aborted the session if relcache lookup happened. example:
> 
> test=# begin;
> BEGIN
> test=*# insert into ttt values(1);
> ERROR:  relation "ttt" does not exist
> LINE 1: insert into ttt values(1);
>                     ^
> test=!# select * from t1;
> FATAL:  Backend throw an error message
> DETAIL:  Exiting current session because of an error from backend
> HINT:  BACKEND Error: "current transaction is aborted, commands ignored until end of transaction block"
> server closed the connection unexpectedly
>         This probably means the server terminated abnormally
>         before or while processing the request.
> The connection to the server was lost. Attempting reset: Succeeded.
> 
> To prevent  this, check the transaction  state and if it's  already in
> aborted state, do not try to  process the command, but just reply back
> to frontend with an error message:
> 
> ERROR:  current transaction is aborted, commands ignored until end of transaction block
> 
> By the way, while implementing the fix, I found old bugs with replication mode.
> 
> - ReadyForQuery() mistakenly called end_internal_transaction() even if
>   it's not in replication/si mode. Moreover,
>   end_internal_transaction() is called even if the internal
>   transaction has not started.
> 
> - end_internal_transaction() did not call pool_unset_failed_transaction();
> 
> These bugs were harmless until I tried to fix the issue (session
> aborting).
> 
> New regression test 078 for this added.
> 
> Discussion: https://www.pgpool.net/pipermail/pgpool-general/2022-April/008155.html
> 
> Branch
> ------
> V4_3_STABLE
> 
> Details
> -------
> https://git.postgresql.org/gitweb?p=pgpool2.git;a=commitdiff;h=22320057bb1c2e3ab13fcb9c9ac585b145f98109
> 
> Modified Files
> --------------
> src/protocol/pool_process_query.c                  |  1 +
> src/protocol/pool_proto_modules.c                  | 70 +++++++++++++++++++++-
> .../tests/078.aborted_transaction/expected.txt     | 28 +++++++++
> .../tests/078.aborted_transaction/test.sh          | 48 +++++++++++++++
> 4 files changed, 144 insertions(+), 3 deletions(-)
>