Re: reorganize "Shared Memory and LWLocks" section of docs - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: reorganize "Shared Memory and LWLocks" section of docs
Date
Msg-id 20240112172350.GB3803561@nathanxps13
Whole thread Raw
In response to Re: reorganize "Shared Memory and LWLocks" section of docs  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: reorganize "Shared Memory and LWLocks" section of docs
List pgsql-hackers
On Fri, Jan 12, 2024 at 09:46:50AM -0600, Nathan Bossart wrote:
> On Fri, Jan 12, 2024 at 05:12:28PM +0300, Aleksander Alekseev wrote:
>> """
>> Any registered shmem_startup_hook will be executed shortly after each
>> backend attaches to shared memory.
>> """
>> 
>> IMO the word "each" here can give the wrong impression as if there are
>> certain guarantees about synchronization between backends. Maybe we
>> should change this to simply "... will be executed shortly after
>> [the?] backend attaches..."
> 
> I see what you mean, but I don't think the problem is the word "each."  I
> think the problem is the use of passive voice.  What do you think about
> something like
> 
>     Each backend will execute the registered shmem_startup_hook shortly
>     after it attaches to shared memory.
> 
>> """
>> should ensure that only one process allocates a new tranche_id
>> (LWLockNewTrancheId) and initializes each new LWLock
>> (LWLockInitialize).
>> """
>> 
>> Personally I think that reminding the corresponding function name here
>> is redundant and complicates reading just a bit. But maybe it's just
>> me.
> 
> Yeah, I waffled on this one.  I don't mind removing it.

Here is a new version of the patch with these changes.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Attachment

pgsql-hackers by date:

Previous
From: Abhijit Menon-Sen
Date:
Subject: Re: Report planning memory in EXPLAIN ANALYZE
Next
From: Melanie Plageman
Date:
Subject: Re: Emit fewer vacuum records by reaping removable tuples during pruning