Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\))
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM
 on-access)
From: Andrey Borodin <x4mmm@yandex-team.ru>
In-Reply-To: 
 <CAAKRu_a-aVGxNEdkJt+96HGryQXuQNuXe+PhR0KcnUhXSOPBJw@mail.gmail.com>
Date: Mon, 14 Jul 2025 11:37:47 +0500
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Andres Freund <andres@anarazel.de>,
 Robert Haas <robertmhaas@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <87DD95AA-274F-4F4F-BAD9-7738E5B1F905@yandex-team.ru>
References: 
 <CAAKRu_ZMw6Npd_qm2KM+FwQ3cMOMx1Dh3VMhp8-V7SOLxdK9-g@mail.gmail.com>
 <CAAKRu_YXP1Us41fkZJeBK5SSj5whNC0C9fZNT6Brdtm+F0agpg@mail.gmail.com>
 <CAAKRu_bAR5uCfjuc06vc_xrZjNCJLs493NgHjTOUDso9qGdE0w@mail.gmail.com>
 <CAAKRu_ac4vUdU-U3ax8j=N8y2OM9-pbFZhafLVfzDOM8MtzvvA@mail.gmail.com>
 <BD5C3345-42F2-4870-89B2-FD8875301714@yandex-team.ru>
 <CAAKRu_a-aVGxNEdkJt+96HGryQXuQNuXe+PhR0KcnUhXSOPBJw@mail.gmail.com>
To: Melanie Plageman <melanieplageman@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/87DD95AA-274F-4F4F-BAD9-7738E5B1F905%40yandex-team.ru>
Precedence: bulk


> On 14 Jul 2025, at 00:15, Melanie Plageman <melanieplageman@gmail.com> =
wrote:
>=20
>>=20
>> 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.
>=20
> 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.=