possible bug in handling of contrecords in dd38ff28ad (Fix recovery_prefetch with low maintenance_io_concurrency)

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: possible bug in handling of contrecords in dd38ff28ad (Fix recovery_prefetch with low maintenance_io_concurrency)
Date: 2023-07-01 13:40:47
Message-ID: 6a1df56e-4656-b3ce-4b7a-a9cb41df8189@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I think there's some sort of bug in how dd38ff28ad deals with
contrecords. Consider something as simple as

pgbench -i -s 100

and then doing pg_waldump on the WAL segments, I get this for every
single one:

pg_waldump: error: error in WAL record at 0/1FFFF98: missing
contrecord at 0/1FFFFE0

This only happens since dd38ff28ad, and revert makes it disappear.

It's possible we still have some issue with contrecords, but IIUC we
fixed those. So unless there's some unknown one (and considering this
seems to happen for *every* WAL segment that's hard to believe), this
seems more like an issue in the error detection.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Drouvot, Bertrand 2023-07-01 14:02:06 Re: ProcessStartupPacket(): database_name and user_name truncation
Previous Message Dean Rasheed 2023-07-01 12:33:40 Re: MERGE ... WHEN NOT MATCHED BY SOURCE