agora inbox for pgsql-hackers@postgresql.org  

help / color / mirror / Atom feed

From: Dmitrii Dolgov <9erthalion6@gmail.com>
Subject: [PATCH v4 6/8] Allow to resize shared memory without restart
Date: Sun, 6 Apr 2025 16:47:16 +0200

Add assing hook for shared_buffers to resize shared memory using space,
introduced in the previous commits without requiring PostgreSQL restart.
Essentially the implementation is based on two mechanisms: a
ProcSignalBarrier is used to make sure all processes are starting the
resize procedure simultaneously, and a global Barrier is used to
coordinate after that and make sure all finished processes are waiting
for others that are in progress.

The resize process looks like this:

* The GUC assign hook sets a flag to let the Postmaster know that resize
  was requested.

* Postmaster verifies the flag in the event loop, and starts the resize
  by emitting a ProcSignal barrier.

* All processes, that participate in ProcSignal mechanism, begin to
  process ProcSignal barrier. First a process waits until all processes
  have confirmed they received the message and can start simultaneously.

* Every process recalculates shared memory size based on the new
  NBuffers and extend it using mremap. One elected process signals the
  postmaster to do the same.

* When finished, every process waits on a global ShmemControl barrier,
  untill all others are finished as well. This way we ensure three
  stages with clear boundaries: before the resize, when all processes
  use old NBuffers; during the resize, when processes have mix of old
  and new NBuffers, and wait until it's done; after the resize, when all
  processes use new NBuffers.

* After all processes are using new value, one of them will initialize
  new shared structures (buffer blocks, descriptors, etc) as needed and
  broadcast new value of NBuffers via ShmemControl in shared memory.
  Other backends are waiting for this operation to finish as well. Then
  the barrier is lifted and everything goes as usual.

Since resizing takes time, we need to take into account that during that time:

- New backends can be spawned. They will check status of the barrier
  early during the bootstrap, and wait until everything is over to work
  with the new NBuffers value.

- Old backends can exit before attempting to resize. Synchronization
  used between backends relies on ProcSignalBarrier and waits for all
  participants received the message at the beginning to gather all
  existing backends.

- Some backends might be blocked and not responsing either before or
  after receiving the message. In the first case such backend still
  have ProcSignalSlot and should be waited for, in the second case
  shared barrier will make sure we still waiting for those backends. In
  any case there is an unbounded wait.

- Backends might join barrier in disjoint groups with some time in
  between. That means that relying only on the shared dynamic barrier is
  not enough -- it will only synchronize resize procedure withing those
  groups. That's why we wait first for all participants of ProcSignal
  mechanism who received the message.

Here is how it looks like after raising shared_buffers from 128 MB to
512 MB and calling pg_reload_conf():

    -- 128 MB
    7f90cde00000-7f90d4fa6000  /dev/zero (deleted)
    7f90d4fa6000-7f914de00000
    7f914de00000-7f915cfa8000  /dev/zero (deleted)
    ^ buffers mapping, ~241 MB
    7f915cfa8000-7f944de00000
    7f944de00000-7f94550a8000  /dev/zero (deleted)
    7f94550a8000-7f94cde00000
    7f94cde00000-7f94d4fe8000  /dev/zero (deleted)
    7f94d4fe8000-7f954de00000
    7f954de00000-7f9554ff6000  /dev/zero (deleted)
    7f9554ff6000-7f958de00000
    7f958de00000-7f959508a000  /dev/zero (deleted)
    7f959508a000-7f95cde00000

    -- 512 MB
    7f90cde00000-7f90d5126000  /dev/zero (deleted)
    7f90d5126000-7f914de00000
    7f914de00000-7f9175128000  /dev/zero (deleted)
    ^ buffers mapping, ~627 MB
    7f9175128000-7f944de00000
    7f944de00000-7f9455528000  /dev/zero (deleted)
    7f9455528000-7f94cde00000
    7f94cde00000-7f94d5228000  /dev/zero (deleted)
    7f94d5228000-7f954de00000
    7f954de00000-7f9555266000  /dev/zero (deleted)
    7f9555266000-7f958de00000
    7f958de00000-7f95954aa000  /dev/zero (deleted)
    7f95954aa000-7f95cde00000

The implementation supports only increasing of shared_buffers. For
decreasing the value a similar procedure is needed. But the buffer
blocks with data have to be drained first, so that the actual data set
fits into the new smaller space.

view thread (424+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: 9erthalion6@gmail.com
  Subject: Re: [PATCH v4 6/8] Allow to resize shared memory without restart
  In-Reply-To: <no-message-id-1132423@localhost>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox