Horton

Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
From: Nathan Bossart <nathandbossart@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>, pgsql-hackers@lists.postgresql.org
Date: 2024-07-15T20:10:15Z
Lists: pgsql-hackers 
On Mon, Jul 15, 2024 at 04:03:13PM -0400, Robert Haas wrote:
> On Mon, Jul 15, 2024 at 2:47 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
>> My understanding is that the correctness of this GUC check hook depends on
>> wal_level being a PGC_POSTMASTER GUC.  The check hook would always return
>> true during startup, and there'd be an additional cross-check in
>> PostmasterMain() that would fail startup if necessary.  After that point,
>> we know that wal_level cannot change, so the GUC check hook for
>> summarize_wal can depend on wal_level.  If it fails, my expectation would
>> be that the server would just ignore that change and continue.
> 
> But how do you know that, during startup, the setting for
> summarize_wal is processed after the setting for wal_level?

You don't, but the GUC check hook should always return true when
summarize_wal is processed first.  We'd rely on the PostmasterMain() check
to fail in that case.

-- 
nathan

Commits

  1. Do not summarize WAL if generated with wal_level=minimal.

  2. Revert "Auto-tune effective_cache size to be 4x shared buffers"

  3. Un-break ecpg test suite under --disable-integer-datetimes.

  4. Again fix initialization of auto-tuned effective_cache_size.

  5. Code review for auto-tuned effective_cache_size.

  6. Auto-tune effective_cache size to be 4x shared buffers