From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Cleanup: PGProc->links doesn't need to be the first field anymore |
Date: | 2024-07-03 22:54:18 |
Message-ID: | 22aa749e-cc1a-424a-b455-21325473a794@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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)
Attachment | Content-Type | Size |
---|---|---|
0001-Lift-limitation-that-PGPROC-links-must-be-the-first-.patch | text/x-patch | 1.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2024-07-03 23:09:54 | Re: race condition in pg_class |
Previous Message | David Rowley | 2024-07-03 21:46:24 | Re: Incorrect Assert in BufFileSize()? |