Re: Add custom EXPLAIN options support to auto_explain

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>
Cc: Lukas Fittl <lukas(at)fittl(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Add custom EXPLAIN options support to auto_explain
Date: 2026-04-06 19:35:00
Message-ID: CA+Tgmob6FPjpWTnXR++7UaCKrfO8S761Uk+sqkMpQrVyGNsXnA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 6, 2026 at 3:27 PM Matheus Alcantara
<matheusssilv97(at)gmail(dot)com> wrote:
> I did another review of 0003 (0001 and 0002 are now committed), focusing
> on auto_explain_split_options(). I didn't find any issues. The code
> coverage looks good - auto_explain_split_options() has nearly 100%
> coverage and the new code paths are well exercised by the tests.

Thanks. I just committed it.

> My concern is about that some cloud providers expose
> shared_preload_libraries as a dropdown without user control over
> ordering. I can be totally wrong, but it seems to me that in this case,
> the provider would need to handle dependencies appropriately or have a
> way to let the user define the ordering. Or, a possible improvement
> would be a post-configuration validation hook that runs after all
> shared_preload_libraries are loaded, allowing deferred validation of
> cross-extension dependencies like these EXPLAIN options (I'm wondering
> that we can have more extension dependencies in the future, e.g
> plan_advice and pg_stat_statements [1])

I think this probably collides rather badly with the GUC machinery:
GUC validation can be deferred "a little bit," but the GUC system
itself decides on the timing of validation, and there's no way for the
GUC's check hook to say "please come back later". I suspect that
property of the GUC system is too deeply embedded for us to think
about changing it.

> That said, I think we should proceed with 0003 as-is and revisit this
> when real-world usage reveals such problems in practice.

Yeah, it's frustrating to not be able to do something better than this
for this release, but the great news is that there will very likely be
another release next year. :-)

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2026-04-06 19:36:15 Re: Add errdetail() with PID and UID about source of termination signal
Previous Message Jimmy Angelakos 2026-04-06 19:33:19 Re: [PATCH] pg_dump: Restore extension config table data before user objects during pg_upgrade