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

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

  1. Lift limitation that PGPROC->links must be the first field

  2. Use dlist/dclist instead of PROC_QUEUE / SHM_QUEUE for heavyweight locks