| 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 |