Re: Proposal: Recent mutated table tracking in memory

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