From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) |
Date: | 2025-07-14 06:37:47 |
Message-ID: | 87DD95AA-274F-4F4F-BAD9-7738E5B1F905@yandex-team.ru |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 14 Jul 2025, at 00:15, Melanie Plageman <melanieplageman(at)gmail(dot)com> wrote:
>
>>
>> Also, I'd prefer "page is not marked all-visible but visibility map bit is set in relation" to emit XX001 for monitoring reasons, but again, this is small note, while I need a broader picture.
>
> Could you clarify what you mean by this? Are you talking about the
> string representation of the visibility map bits in the WAL record
> representations in heapdesc.c?
This might be a bit off-topic for this thread, but as long as the patch touches that code we can look into this too.
If VM bit all-visible is set while page is not all-visible IndexOnlyScan will show incorrect results. I observed this inconsistency few times on production.
Two persistent subsystems (VM and heap) contradict each other, that's why I think this is a data corruption. Yes, we can repair the VM by assuming heap to be the source of truth in this case. But we must also emit ERRCODE_DATA_CORRUPTED XX001 code into the logs. In many cases this will alert on-call SRE.
To do so I propose to replace elog(WARNING,...) with ereport(WARNING,(errcode(ERRCODE_DATA_CORRUPTED),..).
Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-07-14 06:42:15 | Re: comment in index_create "text_eq" should be "texteq" |
Previous Message | Konstantin Knizhnik | 2025-07-14 06:35:53 | Re: Logical replication prefetch |