Re: Improve LWLock tranche name visibility across backends
От | Sami Imseih |
---|---|
Тема | Re: Improve LWLock tranche name visibility across backends |
Дата | |
Msg-id | CAA5RZ0tU9j-jEPUCS0=K6PCzYY=291O9Uky9ndbqH_BDp4Hc=Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Improve LWLock tranche name visibility across backends (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
Ответы |
Re: Improve LWLock tranche name visibility across backends
|
Список | pgsql-hackers |
Thanks for reviewing! > Issue 1 -- > > If I register enough tranches to go to: > > + /* Resize if needed */ > + if (LWLockTrancheNames.shmem->count >= LWLockTrancheNames.shmem->allocated) > + { > + newalloc = pg_nextpower2_32(Max(LWLOCK_TRANCHE_NAMES_INIT_SIZE, LWLockTrancheNames.shmem->allocated+ 1)); > + new_list_ptr = dsa_allocate(LWLockTrancheNames.dsa, newalloc * sizeof(dsa_pointer)); > + new_name_ptrs = dsa_get_address(LWLockTrancheNames.dsa, new_list_ptr); > + memcpy(new_name_ptrs, current_ptrs, LWLockTrancheNames.shmem->allocated * sizeof(dsa_pointer)); > + dsa_free(LWLockTrancheNames.dsa, *current_ptrs); > > then I get: > > ERROR: dsa_area could not attach to a segment that has been freed Will investigate this one and correct in the next rev. > Issue 2 -- > > If an extension calls RequestNamedLWLockTranche() it will register the same > tranche twice: > > (gdb) p LWLockTrancheNames.local[0] > $1 = 0x7acf5a40c420 "pg_playmem" > (gdb) p LWLockTrancheNames.local[97] > $2 = 0x7acf5a40c420 "pg_playmem" Thanks for catching. This one is clear, there is an extra call to register inside RequestNamedLWLockTranche. I'll fix this in the next rev. -- Sami
В списке pgsql-hackers по дате отправления: