Horton

Re: Proposal: Progressive explain

Rafael Thofehrn Castro <rafaelthca@gmail.com>

View thread
From: Rafael Thofehrn Castro <rafaelthca@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: torikoshia <torikoshia@oss.nttdata.com>, Andrei Lepikhov <lepihov@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-04-01T06:23:43Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add some new hooks so extensions can add details to EXPLAIN.

Attachments

Hello again,

> ERROR:  could not attach to dynamic shared area

In addition to that refactoring issue, the current patch had a race
condition in pg_stat_progress_explain to access the DSA of a process
running a query that gets aborted.

While discussing with Robert we agreed that it would be wiser to take
a step back and change the strategy used to share progressive explain
data in shared memory.

Instead of using per backend's DSAs shared via a hash structure I now
define a dsa_pointer and a LWLock in each backend's PGPROC.

A global DSA is created by the first backend that attempts to use
the progressive explain feature. After the DSA is created, subsequent
uses of the feature will just allocate memory there and reference
via PGPROC's dsa_pointer.

This solves the race condition reported by Torikoshi and improves
concurrency performance as now we don't have a global LWLock
controlling shared memory access, but a per-backend LWLock.

Performed the same tests done by Torikoshi and it looks like we are
good now. Even with more frequent inspects in pg_stat_progress_explain
(\watch 0.01).

Rafael.