| From: | Tomas Vondra <tomas(at)vondra(dot)me> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Bernd Helmle <mailings(at)oopsware(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, Michael Banck <mbanck(at)gmx(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Changing the state of data checksums in a running cluster |
| Date: | 2026-03-15 22:56:27 |
| Message-ID: | e9727645-0489-4a6e-bf91-39c27c4987d0@vondra.me |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 3/12/26 23:56, Daniel Gustafsson wrote:
>> On 12 Mar 2026, at 00:56, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
> One thing I forgot to mention was that this patch uncovered the same vmap (and
> fsm) issue as is being discussed in [0]. At the time I didn't connect the dots
> that it was an issue even without this patch so I tried to solve it as part of
> this work. After speaking with Andres I ripped out my attempts and will let
> the other thread take care of the issue independently of this.
>
Yeah, this is quite annoying. It makes 100% sense to wait for the
visibility map to get fixed (by properly WAL-logging it). But I'm not
aware of any such fixes for the FSM though, so I what's the plan for
that? IMO the right solution would be to do proper WAL for FSM, but that
seems like a significant amount of work.
regards
--
Tomas Vondra
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2026-03-15 22:59:04 | Re: Changing the state of data checksums in a running cluster |
| Previous Message | Tomas Vondra | 2026-03-15 22:47:36 | Re: Changing the state of data checksums in a running cluster |