| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(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:03:13 |
| Message-ID: | CA+TgmoaKqLrkjEg1j6NEHcMUj-Qk6yUK=qfFzy+G-w6OVVv+0Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2024-07-15 20:04:53 | Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions |
| Previous Message | Arjan Marku | 2024-07-15 19:59:24 | Re: [PATCH v1] Fix parsing of a complex type that has an array of complex types |