Re: Follow-up fixes for online wal_level change - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Follow-up fixes for online wal_level change
Date
Msg-id CAD21AoApAnRSH_p99f5+KyugK+yeTsF4hdNVdvwGjNHcohMQMQ@mail.gmail.com
Whole thread
In response to RE: Follow-up fixes for online wal_level change  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
List pgsql-hackers
On Thu, Jul 16, 2026 at 8:35 PM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.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



pgsql-hackers by date:

Previous
From: Jehan-Guillaume de Rorthais
Date:
Subject: Re: Possible Visibility Map corruption in supported branches?
Next
From: Scott Ray
Date:
Subject: Re: Report oldest xmin source when autovacuum cannot remove tuples