Re: Clarification on when _PG_init() is invoked for extensions

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

>

In response to

Browse pgsql-hackers by date

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