| 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: | Whole Thread | Raw Message | 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()? |