Re: Improve LWLock tranche name visibility across backends - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: Improve LWLock tranche name visibility across backends
Date
Msg-id CAA5RZ0tU9j-jEPUCS0=K6PCzYY=291O9Uky9ndbqH_BDp4Hc=Q@mail.gmail.com
Whole thread Raw
In response to Re: Improve LWLock tranche name visibility across backends  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Improve LWLock tranche name visibility across backends
List 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 by date:

Previous
From: Jacob Champion
Date:
Subject: Re: libpq-oauth: a mid-beta naming check
Next
From: Christoph Berg
Date:
Subject: Re: libpq-oauth: a mid-beta naming check