Re: Follow-up fixes for online wal_level change

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Follow-up fixes for online wal_level change
Date: 2026-07-17 17:56:15
Message-ID: CAD21AoApAnRSH_p99f5+KyugK+yeTsF4hdNVdvwGjNHcohMQMQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 16, 2026 at 8:35 PM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> Dear Fujii-san,
>
> > Should this status be exposed also by pg_control_checkpoint()?
>
> Oh I didn't know the function, yes, seems to be exposed as well.
>
> While checking the function, I found that CheckPoint:: wal_level is not
> shown by the code function as well. Should we handle that?
> I think pg_controldata command does not have to output the attribute because
> ControlFileData::wal_level is also printed, but not sure the SQL function.
>

ControlFileData.wal_level and ControlFileData.checkPointCopy.wal_level
are different and the only former is currently shown in pg_controldata
and the pg_control_XXX() function family. Considering the
ControlFileData.wal_level is effectively the same as wal_level GUC
value, I think we don't need to show it in pg_control_XXX() functions.
As for the latter, it might be useful for debugging to expose it in a
few cases and we might want to show it in both places if we want. But
I'm not sure it's worth the confusion it could cause. I think it
should be for PG20 anyway.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Scott Ray 2026-07-17 18:11:54 Re: Report oldest xmin source when autovacuum cannot remove tuples
Previous Message Jehan-Guillaume de Rorthais 2026-07-17 17:52:43 Re: Possible Visibility Map corruption in supported branches?