Granulaur spinlock wait events

From: Zaeem Hussain <zaeem(dot)hussain(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Granulaur spinlock wait events
Date: 2025-08-08 18:19:18
Message-ID: CA+XmnEaf0pogPwSjGS4R70ZLgw4e+NEeRoP6=XCDVFW8Wcqosg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I am a software engineer with Google's AlloyDB. We recently implemented
more granular spinlock wait event tracking and I wanted to propose it here.
I can create a patch if the community here deems it suitable for
incorporating into postgres. Here is the overall idea:
We categorise the spinlocks based on the location (filename and line
number) where they are initialized (via SpinLockInit).
We change slock_t to a struct that contains the actual lock variable and an
id (we just need a byte for it). We also allocate a shared memory array
(128 entries by 128 bytes) for storing the filename:line_number
identifiers. During SpinLockInit, we use the filename:line_number combo of
the caller and do a lookup for it in the array, adding an entry if the
combination is not found. The index of the entry is the identifier that
will be stored in the lock struct. This identifier is then set in the
SpinDelayStatus which is then used to set the new wait event id when
reporting SpinDelay (we add a new wait event class for SpinLock). The name
of the wait event is of the form 'SpinLock_filename:linenum'.

Pros of this approach: The changes are pretty much limited to the spinlock
related files and the APIs for SpinLock initialization, acquisition and
release do not change. There is also no additional overhead during spinlock
acuire and release.
Cons of this approach: Overhead of storing the id with each lock and extra
work during SpinLockInit.

We adopted this approach internally since we did not notice performance
regressions in our tests. However, the platforms we run on with AlloyDB are
only a subset of what postgres supports, so I am open to doing additional
testing on my patch if there are suggestions (right now it passes 'make
check' on my local build).

I would appreciate any feedback and suggestions on this.

Zaeem

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2025-08-08 18:31:22 Re: SCRAM pass-through authentication for postgres_fdw
Previous Message Sami Imseih 2025-08-08 18:09:29 Re: Improve LWLock tranche name visibility across backends