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
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 |