Date: Fri, 26 Jun 2026 07:40:28 +0900 (JST)
Message-Id: <20260626.074028.806271918741516663.ishii@postgresql.org>
To: nadav@tailorbrands.com
Cc: pgpool-hackers@lists.postgresql.org
Subject: Re: Proposal: Recent mutated table tracking in memory
From: Tatsuo Ishii <ishii@postgresql.org>
In-Reply-To: 
 <CACeKOO31reCtDYU1twicmqgdEStCJXWJ6P4LMFMYytaYaGew-A@mail.gmail.com>
References: 
 <CACeKOO02V7_SBpCUJWG7yS-ABNEXzAAU-vb+JrY=rD8yBiiy0g@mail.gmail.com>
	<20260619.111037.159094338431818955.ishii@postgresql.org>
	<CACeKOO31reCtDYU1twicmqgdEStCJXWJ6P4LMFMYytaYaGew-A@mail.gmail.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20260626.074028.806271918741516663.ishii%40postgresql.org>
Precedence: bulk

Hi Nadav,

> Hi Tatsuo,
> 
> Good catch -- that was a bug, and chasing it down turned up a second
> one in the same area.
> 
> The original problem you described: the flush ran in dml_adaptive()
> while pgpool was *routing* the COMMIT, before the COMMIT was sent to
> the backend.  So a COMMIT that later failed (your deferred-constraint
> example) had already marked the tables, even though the writes rolled
> back.
> 
> My first instinct was to just move the flush to handle_query_context(),
> where reaching CommandComplete for the COMMIT means it succeeded.  But
> that path resolves table/database OIDs via pool_table_name_to_oid() /
> the relcache, which on a cache miss issues a do_query() -- and at that
> point the COMMIT response is still being read from the backend, so
> injecting a query desyncs the protocol and hangs the session.  Testing
> caught this immediately.
> 
> It turned out the existing autocommit marking branch had the very same
> hazard: pool_extract_table_oids() in handle_query_context() also does a
> relcache do_query() on a miss, so e.g. "DROP TABLE IF EXISTS <nonexistent>"
> (an uncacheable name -> guaranteed miss) reliably hung the session too.

Are you saying that the non patched pgpool has a problem?
I tried following queries with master branch and found no hang.

BEGIN;
DROP TABLE IF EXISTS non_existent_table;
COMMIT;

Regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp