| From: | Robert Haas <robertmhaas(at)gmail(dot)com> | 
|---|---|
| To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: Memory context at PG_init call ? | 
| Date: | 2015-06-23 13:48:15 | 
| Message-ID: | CA+TgmoYZUxz3PupcXaBTfJzu0sUur8JPMcjPJA2HU_F2rjsPrQ@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Tue, Jun 23, 2015 at 7:41 AM, Sandro Santilli <strk(at)keybit(dot)net> wrote:
> Empirically, I seem to be getting the _PG_init call for a module while
> the active memory context lifetime is that of the function call which
> first needed to load the shared object.
>
> Is this the case ? Documented anywhere ?
> Initializing memory meant to be alive for the whole lifetime of a backend
> in that function is a bit complex if that's confirmed.
If you want something that lasts for the lifetime of the backend, just do
MemoryContext oldctx = MemoryContextSwitchTo(TopMemoryContext);
...
MemoryContextSwitchTo(oldctx);
I'm not sure what context you should expect in _PG_init(), although
what you mention doesn't sound unreasonable.  But generally if you
want a long-lived context you should establish that explicitly
yourself.  We try to keep short-lived contexts active whenever
possible because that avoids long-term leaks.
-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2015-06-23 13:49:53 | Re: Insufficient locking for ALTER DEFAULT PRIVILEGES | 
| Previous Message | Robert Haas | 2015-06-23 13:20:21 | Re: less log level for success dynamic background workers for 9.5 |