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

From Rahila Syed
Subject Re: Improve LWLock tranche name visibility across backends
Date
Msg-id CAH2L28uCaeuyz9iZOfHK_XPaJw06whE+92g0pGW6PytV1YHSbg@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
Hi,

I've begun reviewing this patch and have a few questions listed below:

1.   + if (i < LWLockTrancheNames.shmem->allocated && DsaPointerIsValid(old_ptrs[i]))
           
Should an assert be used for the second condition instead?
Since for i < LWLockTrancheNames.shmem->allocated, the dsa pointer is expected to be valid.  

2.                                copied_ptr = dsa_allocate(LWLockTrancheNames.dsa, len);
+
+                               copied_addr = dsa_get_address(LWLockTrancheNames.dsa, copied_ptr);
+                               memcpy(copied_addr, old_name, len);
+
+                               new_ptrs[i] = copied_ptr;
+
+                               /* free old tranche names */
+                               dsa_free(LWLockTrancheNames.dsa, old_ptrs[i]);

Why is it necessary to allocate a new dsa_pointer for tranche names that are the same size and then
free the old one?
Is there a reason we can't just assign new_ptrs[i] = old_ptrs[i]?

3. 
>Additionally, while users should not pass arbitrary tranche IDs (that is,
>IDs not created via LWLockNewTrancheId) to LWLockInitialize, nothing
>technically prevents them from doing so. Therefore, we must continue to
>handle such cases gracefully by returning a default "extension" tranche name.

Would it be possible to update LWLockInitialize so that it checks if tranche_id is
already registered in the dsa, and if not, registers it during the LWLockInitialize() process?  

Thank you,
Rahila Syed                                 

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: [(known) BUG] DELETE/UPDATE more than one row in partitioned foreign table
Next
From: 厉超
Date:
Subject: Re: Re: Enhance Makefiles to rebuild objects on map file changes