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