Re: Inherited UPDATE/DELETE vs async execution

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Inherited UPDATE/DELETE vs async execution
Date: 2021-05-10 12:20:52
Message-ID: CA+HiwqGLnKcB-dVcwGrQiovCkcTP-M-21nrKQcNfda5jrhH1NA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fujita-san,

On Sat, May 8, 2021 at 1:21 AM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
> I noticed this while working on the
> EXPLAIN-ANALYZE-for-async-capable-nodes issue:
>
> EXPLAIN (VERBOSE, COSTS OFF)
> DELETE FROM async_pt;
> QUERY PLAN
> ----------------------------------------------------------------
> Delete on public.async_pt
> Foreign Delete on public.async_p1 async_pt_1
> Foreign Delete on public.async_p2 async_pt_2
> Delete on public.async_p3 async_pt_3
> -> Append
> -> Async Foreign Delete on public.async_p1 async_pt_1
> Remote SQL: DELETE FROM public.base_tbl1
> -> Async Foreign Delete on public.async_p2 async_pt_2
> Remote SQL: DELETE FROM public.base_tbl2
> -> Seq Scan on public.async_p3 async_pt_3
> Output: async_pt_3.tableoid, async_pt_3.ctid
> (11 rows)
>
> DELETE FROM async_pt;
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> connection to server was lost
>
> The cause for this would be that direct-update plans are mistakenly
> treated as async-capable ones, as shown in the EXPLAIN output.

I guess that happens because the ForeignScan nodes responsible for
scanning or direct-updating/deleting from child foreign tables appear
under an Append as of 86dc90056, whereas before they would appear as
child plans of a ModifyTable node. IIUC, it's the Append that causes
the async_capable flag to be set in those ForeignScan nodes.

> To
> fix, I think we should modify postgresPlanDirectModify() so that it
> clears the async-capable flag if it is set. Attached is a patch for
> that. Maybe I am missing something, though.

I see that your patch is to disable asynchronous execution in
ForeignScan nodes responsible for direct update/delete, but why not do
the same for other ForeignScan nodes too? Or the other way around --
is it because fixing the crash that occurs in the former's case would
be a significant undertaking for little gain?

--
Amit Langote
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message tanghy.fnst@fujitsu.com 2021-05-10 12:26:55 RE: Remove "FROM" in "DELETE FROM" when using tab-completion
Previous Message Peter Eisentraut 2021-05-10 11:59:16 Re: [PATCH] Identify LWLocks in tracepoints