Re: [HACKERS] Error: dsa_area could not attach to a segment that hasbeen freed - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: [HACKERS] Error: dsa_area could not attach to a segment that hasbeen freed
Date
Msg-id CAEepm=3y4EjCJBqW12DiJ1w8U9x5_bJPPyUJn1uOeB+zertnBw@mail.gmail.com
Whole thread Raw
In response to [HACKERS] Error: dsa_area could not attach to a segment that has been freed  (Gaddam Sai Ram <gaddamsairam.n@zohocorp.com>)
Responses Re: [HACKERS] Error: dsa_area could not attach to a segment thathas been freed
List pgsql-hackers
On Fri, Sep 15, 2017 at 7:51 PM, Gaddam Sai Ram
<gaddamsairam.n@zohocorp.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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Make WAL segment size configurable at initdb time.