Inherited UPDATE/DELETE vs async execution

From: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Inherited UPDATE/DELETE vs async execution
Date: 2021-05-07 16:20:51
Message-ID: CAPmGK158e9sJOfuWxfn+0ynrspXQU3JhNjSCbaoeSzMvnga+bw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Best regards,
Etsuro Fujita

Attachment Content-Type Size
fix-postgresPlanDirectModify.patch application/octet-stream 3.9 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-05-07 16:22:51 Draft back-branch release notes are up
Previous Message Etsuro Fujita 2021-05-07 16:05:47 Re: Asynchronous Append on postgres_fdw nodes.