Re: Changing shared_buffers without restart

Hi Ashutosh,

I reviewed the v20260817 patches, and here is what I found:

0003 / 0004:

BufTableGetContents() holds all mapping partition locks for the whole scan,
with no CHECK_FOR_INTERRUPTS. pg_buffercache_lookup_table is a view whose name
ends in "table", which is ambiguous. What about pg_buffercache_mappings?

With a resize pending, pg_settings.setting reads "16384 (pending: 32768)",
could break pg_size_bytes(current_setting('shared_buffers')). Maybe we need a
new GUC rather than a composite one.

0006:

configure hasn't been regenerated. The feature might not be compiled by default.

Shrinking PANICs, whenever max_shared_buffers > shared_buffers.
The range handed to madvise(MADV_REMOVE) in ShmemResizeStruct() ends at
maximum_size rather than at the current size, so it covers the PROT_NONE tail
and fails with EACCES.

There are now six read-only shared_memory_* values, and the names are getting
long. A function might fit better than that many GUCs.
shared_memory_size_in_huge_pages is gone, it might break compatibility.

MADV_POPULATE_WRITE requires a new OS kernel version. #ifdef is needed in
PGSharedMemoryEnsureAllocated.

"could not protect shared memory" is emitted from two places, so it's not
possible to tell which one failed.

0007:

EvictExtraBuffers() checks BM_VALID, but BM_TAG_VALID is the flag that means
there's a mapping table entry, so buffers with IO in flight are skipped by the
precheck.

"shared buffer resizing to %d buffers failed" doesn't say why it failed.

Some values like MaxProportionalPins aren't recomputed on resize.

001_resize_fault_tolerance.pl never reaches madvise(): with
max_shared_buffers = 32 buffers and huge pages still on for the TAP cluster,
the range rounds away at 2MB granularity, so everything passes with nothing
freed. That is also why the shrink problem above goes unnoticed.

Best Regards,
Yuhang Qiu.