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

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal
Date: 2024-07-15 20:10:15
Message-ID: ZpWCJxL3tQm3lkLI@nathan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stepan Neretin 2024-07-15 20:31:19 Re: Sort functions with specialized comparators
Previous Message Robert Haas 2024-07-15 20:04:53 Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions