Re: Odd usage of errmsg_internal in bufmgr.c

From: Andres Freund <andres(at)anarazel(dot)de>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Odd usage of errmsg_internal in bufmgr.c
Date: 2026-02-12 19:12:14
Message-ID: aY4jZ-_rJR-VHAC0@alap3.anarazel.de
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2026-02-12 18:53:34 +0100, Álvaro Herrera wrote:
> I'm confused about the meaning of "Block [first+first_off] held the
> first invalid page.", though ... what exactly does that mean? What does
> (first+first_off) represent? Block of what? How is (first) different
> from (first+first_off)? The comments on buffer_readv_decode_error() and
> buffer_readv_encode_error() leave me none the wiser. Is the segment
> size relevant to how I must interpret that number?

It's relevant for IOs that are larger than one block. E.g. you could have an
IO reading in three blocks, where there are checksum errors on the second and
third block, but the first block is OK. Or just one checksum error in a 16
block IO.

Because the error can be detected e.g. in an IO worker, we have to encode
information about the error in a dense way, since it has to be forwarded
through shared memory. Reporting the number of invalid pages / checksum
failures / zeroed pages, and the first affected block seemed a decent
compromise between space and precision.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2026-02-12 19:16:52 Re: Odd usage of errmsg_internal in bufmgr.c
Previous Message Tom Lane 2026-02-12 19:04:39 Re: pgsql: Add file_extend_method=posix_fallocate,write_zeros.