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 по дате отправления: