| From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
|---|---|
| To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Subject: | Re: Why clearing the VM doesn't require registering vm buffer in wal record |
| Date: | 2026-09-21 21:20:40 |
| Message-ID: | CAAKRu_Y0z2KyU6BcVzzgA--rMieu5cWUBgPdufiZLJeHc6x92A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Sep 17, 2026 at 5:25 AM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
> On 16 Sep 2026, Melanie Plageman wrote:
> > Vacuum works very hard to never end up with
> > PD_ALL_VISIBLE cleared and the VM set. Perhaps we should do everything
> > we can to avoid this happening with page modifications as well.
>
> Would it be practical to assert that the VM all-visible bit is clear
> whenever we clear PD_ALL_VISIBLE? There may be reasons we don't already
> do this that I'm missing, especially during recovery when pages can be
> ahead of the record being replayed. It seems like a useful check if we
> can find the right conditions for it.
That wouldn't help in this case because it was already clear on the
primary. The problem is that the VM was set on the standby. I am going
to propose some patches to try and repair VM corruption in more cases
and warn when doing so so we know when things got out of sync. But we
can't catch this before it happens when clearing the VM on the primary
if it is already in the right state.
- Melanie
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zsolt Parragi | 2026-09-21 21:38:56 | Re: Stabilize and shorten test_checksums/013_rewind test |
| Previous Message | Alexandre Felipe | 2026-09-21 21:15:18 | Re: aio: worker: Free SMGR objects when idle |