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: | Whole Thread | Raw Message | 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
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 |