[HACKERS] Error: dsa_area could not attach to a segment that has been freed

Поиск
Список
Период
Сортировка
От Gaddam Sai Ram
Тема [HACKERS] Error: dsa_area could not attach to a segment that has been freed
Дата
Msg-id 15e84857859.d4f2ff2b8299.3910523281971861294@zohocorp.com
обсуждение исходный текст
Ответы [HACKERS] Re: Error: dsa_area could not attach to a segment that has beenfreed  (Gaddam Sai Ram <gaddamsairam.n@zohocorp.com>)
Re: [HACKERS] Error: dsa_area could not attach to a segment that hasbeen freed  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список pgsql-hackers
Hello everyone, 

Based on the discussion in the below thread, I built a an extension using DSA(postgres-10 beta-3, linux machine).

Use _PG_init and the shmem hook to reserve a little bit of
traditional shared memory and initialise it to zero.  This will be
used just to share the DSA handle, but you can't actually create the
DSA area in postmaster.  In other words, this little bit of shared
memory is for "discovery", since it can be looked up by name from any
backend.
Yes, I have created memory for DSA handle in shared memory, but not the actual DSA area.

In each backend that wants to use your new in-memory index system,
you need to be able to attach or create the DSA area on-demand.
Perhaps you could have a get_my_shared_state() function (insert better
name) that uses a static local variable to hold a pointer to some
state.  If it's NULL, you know you need to create the state.  That
should happen only once in each backend, the first time through the
function.  In that case you need to create or attach to the DSA area
as appropriate, which you should wrap in
LWLockAcquire(AddinShmemInitLock,
LW_EXCLUSIVE)/LWLockRelease(AddinShmemInitLock) to serialise the code
block.  First, look up the bit of traditional shared memory to see if
there is a DSA handle published in it already.  If there is you can
attach.  If there isn't, you are the first so you need to create, and
publish the handle for others to attach to.  Remember whatever state
you need to remember, such as the dsa_area, in static local variables
so that all future calls to get_my_shared_state() in that backend will
be fast.
Yes, the code is present in gstore_shmem.c(pfa) and the first process to use DSA will create the area, and rest all new processes will either attach it or if it is already attached, it will use the DSA area which is already pinned.


==> I have created a bgworker in pg_init and when it starts it will be the first process to access DSA, so it will create DSA area.
==> I have a small UDF function(simple_udf_func) which I call in a new backend(process). So it will attach the DSA area already created.
==> When I make a call to same UDF function again in the same process, since the area is already attached and pinned, I use the same area which I store in a global variable while attaching/creating. Here I get the problem...

Error details: dsa_area could not attach to a segment that has been freed

While examining in detail, I found this data.
I used dsa_dump() for debugging and I found that during my error case, i get this log:

dsa_area handle 1:
  max_total_segment_size: 0
  total_segment_size: 0
  refcnt: 0
  pinned: f
  segment bins:
  segment bin 0 (at least -2147483648 contiguous pages free):


Clearly, the data in my DSA area has been corrupted in latter case, but my bgworker continues to work proper with same dsa_area handle.

At this stage, the dsa_dump() in my bgworker is as below:

dsa_area handle 1814e630:
  max_total_segment_size: 18446744073709551615
  total_segment_size: 1048576
  refcnt: 3
  pinned: t
  segment bins:
    segment bin 8 (at least 128 contiguous pages free):
      segment index 0, usable_pages = 253, contiguous_pages = 220, mapped at 0x7f0abbd58000

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. 


Regards
G. Sai Ram





Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] Setting pd_lower in GIN metapage
Следующее
От: "Tsunakawa, Takayuki"
Дата:
Сообщение: Re: [HACKERS] Re: [bug fix] PG10: libpq doesn't connect toalternative hosts when some errors occur