Re: reorganize "Shared Memory and LWLocks" section of docs

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Aleksander Alekseev <aleksander(at)timescale(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: reorganize "Shared Memory and LWLocks" section of docs
Date: 2024-01-12 17:23:50
Message-ID: 20240112172350.GB3803561@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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:

Attachment Content-Type Size
v2-0001-reorganize-shared-memory-and-lwlocks-documentatio.patch text/x-diff 9.3 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2024-01-12 17:33:28 Re: Emit fewer vacuum records by reaping removable tuples during pruning
Previous Message Abhijit Menon-Sen 2024-01-12 17:23:08 Re: Report planning memory in EXPLAIN ANALYZE