From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Gaddam Sai Ram <gaddamsairam(dot)n(at)zohocorp(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Error: dsa_area could not attach to a segment that has been freed |
Date: | 2017-09-20 05:46:19 |
Message-ID: | CAEepm=3y4EjCJBqW12DiJ1w8U9x5_bJPPyUJn1uOeB+zertnBw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 15, 2017 at 7:51 PM, Gaddam Sai Ram
<gaddamsairam(dot)n(at)zohocorp(dot)com> wrote:
> As i'm pinning the dsa mapping after attach, it has to stay through out the
> backend session. But not sure why its freed/corrupted.
>
> Kindly help me in fixing this issue. Attached the copy of my extension,
> which will reproduce the same issue.
Your DSA area is pinned and the mapping is pinned, but there is one
more thing that goes away automatically unless you nail it to the
table: the backend-local dsa_area object which dsa_create() and
dsa_attach() return. That's allocated in the "current memory
context", so if you do it from your procedure simple_udf_func without
making special arrangements it gets automatically freed at end of
transaction. If you're going to cache it for the whole life of the
backend, you'd better make sure it's allocated in memory context that
lives long enough. Where you have dsa_create() and dsa_attach()
calls, try coding like this:
MemoryContext old_context;
old_context = MemoryContextSwitchTo(TopMemoryContext);
area = dsa_create(...);
MemoryContextSwitchTo(old_context);
old_context = MemoryContextSwitchTo(TopMemoryContext);
area = dsa_attach(...);
MemoryContextSwitchTo(old_context);
You'll need to #include "utils/memutils.h".
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-09-20 05:51:45 | Re: [COMMITTERS] pgsql: Make WAL segment size configurable at initdb time. |
Previous Message | Achilleas Mantzios | 2017-09-20 05:43:36 | Re: [HACKERS] USER Profiles for PostgreSQL |