From: | Aleksander Alekseev <aleksander(at)tigerdata(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Subject: | Re: VM corruption on standby |
Date: | 2025-08-07 16:36:24 |
Message-ID: | CAJ7c6TP3prGJM4DCspkv9CVcHbXbxwOMEN_8XgRGAbj18pN5nQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Andrey,
> the test passes because you moved injection point to a very safe position
> [...]
> I want to emphasize that it seems to me that position of injection point is not a hint, but rather coincidental.
Well, I wouldn't say that the test passes merely because the location
of the injection point was moved.
For sure it was moved, because the visibilitymap_clear() call was
moved. Maybe I misunderstood the intent of the test. Wasn't it to call
the injection point right after updating the VM? I tried to place it
between updating the WAL and updating the VM and the effect was the
same - the test still passes.
In any case we can place it anywhere we want to if we agree to include
the test into the final version of the patch.
> I concur that all other users of visibilitymap_clear() likely will need to be fixed.
Right, I realized there are a few places besides heapam.c that might
need a change.
> The approach seems viable to me, but I'd like to have understanding why PD_ALL_VISIBLE in a heap page header did not save the day before fixing anything
> ... But only when we have a good picture what exactly is broken.
Agree. I especially would like to know the opinion of somebody who's
been hacking Postgres longer than I did. Perhaps there was a good
reason to update the VM *before* creating WAL records I'm unaware of.
From | Date | Subject | |
---|---|---|---|
Next Message | Mat Arye | 2025-08-07 16:46:47 | Read-only connection mode for AI workflows. |
Previous Message | Dagfinn Ilmari Mannsåker | 2025-08-07 16:35:29 | Re: [PATCH] OAuth: fix performance bug with stuck multiplexer events |