Re: Add Postgres module info

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Yurii Rashkovskii <yrashk(at)omnigres(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add Postgres module info
Date: 2025-03-24 14:11:55
Message-ID: c41a4cbc-608f-45ff-8642-49ffc7c85745@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/23/25 20:10, Tom Lane wrote:
> Andrei Lepikhov <lepihov(at)gmail(dot)com> writes:
>> On 3/22/25 23:49, Tom Lane wrote:
>>> * It is not clear to me what permission restrictions we should put
>>> on pg_get_loaded_modules, ...
>
>> I vote for the idea of stripping the full path to just a filename.
>
> Works for me. v7 attached does it that way.
Thanks, you've done almost all the job.
>
>>> * I'm not happy with putting pg_get_loaded_modules into dfmgr.c.
>
>> I just attempted to reduce number of exported objects here. If it is ok
>> to introduce an iterator, the pg_get_loaded_modules() may live in
>> extension.c
>
> Yeah, I like that better than leaving it in dfmgr.c, so done that way.
> The iterator functions also provide some cover for dealing with
> on-the-fly changes of the file list, if we ever need that.
It also gives extension developers a tool to detect conflicting modules
any time we need it. More elegant than the SerializeLibraryState().
>
> I converted pg_get_loaded_modules to run just once and deliver its
> results in a tuplestore. That's partly because the adjacent SRFs
> in extension.c work like that, but mostly because it removes the
> hazard of the file list changing mid-run.
Ok.
>> Yes, additional burden to bump version string was a stopper for me to
>> propose such a brave idea.
>
> After sleeping on it, I think we really ought to do that, so 0002
> attached does so.
With the concept of the PG_VERSION string as a version, it looks more
meaningful than I've thought before.

Patch 0001 is ready to commit for me.
Patch 0002 I just checked on the errors in module names. That's more I
can do here? ;) Seems good, no errors found.

--
regards, Andrei Lepikhov

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message torikoshia 2025-03-24 14:18:07 Re: Change log level for notifying hot standby is waiting non-overflowed snapshot
Previous Message Amit Langote 2025-03-24 13:52:58 Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning