| From: | Rahila Syed <rahilasyed90(at)gmail(dot)com> |
|---|---|
| To: | Ayush Vatsa <ayushvatsa1810(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Clarification on when _PG_init() is invoked for extensions |
| Date: | 2025-11-21 04:28:23 |
| Message-ID: | CAH2L28tHEjOr5gK187JzKS14uxYWd_S==aRUPE9OQ412yKAsow@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
>
> CREATE extension does not automatically load or ensure that _PG_init() is
>> run.
>> It mainly runs the .sql script in your extension.
>>
> Thanks for the clarification. However, in my testing, _PG_init() did run
> when I executed
> CREATE EXTENSION. I suspect this might be happening because the SQL
> script defines
> C functions using MODULE_PATHNAME, which triggers the library load.
> In a new session, _PG_init() seems to run again when any of those C
> functions are executed.
>
>
You are right, if the create extension creates a C function it triggers the
load of the library, which
in turn causes _PG_init() to execute.
Sorry for the confusion.
FWIW, the call stack looks like the following:
_PG_init ()
internal_load_library()
load_external_function ()
fmgr_c_validator ()
FunctionCall1Coll ()
OidFunctionCall1Coll ()
ProcedureCreate ()
CreateFunction ()
ProcessUtilitySlow ()
standard_ProcessUtility ()
ProcessUtility ()
execute_sql_string ()
execute_extension_script ()
CreateExtensionInternal ()
CreateExtension ()
Thank you,
Rahila Syed
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2025-11-21 04:28:37 | Re: How can end users know the cause of LR slot sync delays? |
| Previous Message | Zhijie Hou (Fujitsu) | 2025-11-21 03:47:30 | RE: Assertion failure in SnapBuildInitialSnapshot() |