Cleanup: PGProc->links doesn't need to be the first field anymore
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-07-03T22:54:18Z
Lists: pgsql-hackers
Attachments
- 0001-Lift-limitation-that-PGPROC-links-must-be-the-first-.patch (text/x-patch) patch 0001
pgproc.h has this:
> struct PGPROC
> {
> /* proc->links MUST BE FIRST IN STRUCT (see ProcSleep,ProcWakeup,etc) */
> dlist_node links; /* list link if process is in a list */
> dlist_head *procgloballist; /* procglobal list that owns this PGPROC */
> ...
I don't see any particular reason for 'links' to be the first field. We
used to do things like "proc = (PGPROC *) waitQueue->links.next", but
since commit 5764f611e1, this has been a "dlist", and dlist_container()
can handle the list link being anywhere in the struct.
I tried moving it and ran the regression tests. That revealed one place
where we still don't use dlist_container:
> if (!dlist_is_empty(procgloballist))
> {
> MyProc = (PGPROC *) dlist_pop_head_node(procgloballist);
> ...
I believe that was just an oversight. Trivial patch attached.
--
Heikki Linnakangas
Neon (https://neon.tech)
Commits
-
Lift limitation that PGPROC->links must be the first field
- 98347b5a3ab1 18.0 landed
-
Use dlist/dclist instead of PROC_QUEUE / SHM_QUEUE for heavyweight locks
- 5764f611e10b 16.0 cited