Horton

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, x4mmm@yandex-team.ru, dilipbalaut@gmail.com, tndrwang@gmail.com, pgsql-hackers@lists.postgresql.org, tomas.vondra@enterprisedb.com
Date: 2024-03-04T22:14:32Z
Lists: pgsql-hackers 
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Pushed that way, but we can discuss further wording improvements/changes
> if someone wants to propose any.

I just noticed that drongo is complaining about two lines added
by commit 53c2a97a9:

 drongo        | 2024-03-04 14:34:52 | ../pgsql/src/backend/access/transam/slru.c(436): warning C4047: '!=': 'SlruPageStatus *' differs in levels of indirection from 'int'
 drongo        | 2024-03-04 14:34:52 | ../pgsql/src/backend/access/transam/slru.c(717): warning C4047: '!=': 'SlruPageStatus *' differs in levels of indirection from 'int'

These lines are

	Assert(&shared->page_status[slotno] != SLRU_PAGE_EMPTY);

	Assert(&ctl->shared->page_status[slotno] != SLRU_PAGE_EMPTY);

These are comparing the address of something with an enum value,
which surely cannot be sane.  Is the "&" operator incorrect?

It looks like SLRU_PAGE_EMPTY has (by chance, or deliberately)
the numeric value of zero, so I guess the majority of our BF
animals are understanding this as "address != NULL".  But that
doesn't look like a useful test to be making.

			regards, tom lane

Commits

  1. Fix zeroing of pg_serial page without SLRU bank lock

  2. Fix misspelled assertions

  3. GUC table: Add description to computed variables

  4. Improve performance of subsystems on top of SLRU

  5. Rename SLRU elements in view pg_stat_slru

  6. Use atomic access for SlruShared->latest_page_number

  7. Split use of SerialSLRULock, creating SerialControlLock

  8. Index SLRUs by 64-bit integers rather than by 32-bit integers

  9. Add a macro templatized hashtable.