Re: Proposal: Progressive explain

From: Rafael Thofehrn Castro <rafaelthca(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Progressive explain
Date: 2025-03-26 21:57:54
Message-ID: CAG0ozMq48+ODFoLW4HHexN8BKHfh_4c-n2b=yH9oaUnCZNZj6Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Suppose:
> BEGIN;
> SELECT 1;
> SAVEPOINT bob;
> progressively explain something that aborts
> I think in this case we will call AbortSubTransaction(), not
AbortTransaction().

Indeed. We need special treatment for subtransactions. There are 2
scenarios where
AbortSubTransaction() will be called alone and can affect progressive
explains:
savepoints and PL/pgSQL exception blocks.

We don't want subxact aborts in PL/pgSQL exception blocks to perform cleanup
as the original query will continue to run and progressive explain tracking
is still applicable there.

So implementation was done based on transaction nested level. Cleanup is
only
performed when AbortSubTransaction() is called in the same transaction
nested
level as the one where the query is running. This covers both PL/pgSQL
exception
blocks and savepoints.

Rafael.

Attachment Content-Type Size
v13-0001-Proposal-for-progressive-explains.patch application/octet-stream 90.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-03-26 22:13:08 Re: sync_standbys_defined read/write race on startup
Previous Message Thomas Munro 2025-03-26 21:52:10 Re: AIO v2.5