has_wal_read_bug

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Noah Misch <noah(at)leadboat(dot)com>
Subject: has_wal_read_bug
Date: 2022-05-16 23:50:51
Message-ID: CA+hUKGLZ=_vS44syPh+2sKNv6tdR+83CU_xV=Qzy08EQ+SEo-g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

027_stream_regress.pl has:

if (PostgreSQL::Test::Utils::has_wal_read_bug)
{
# We'd prefer to use Test::More->builder->todo_start, but the bug causes
# this test file to die(), not merely to fail.
plan skip_all => 'filesystem bug';
}

Is the die() referenced there the one from the system_or_bail() call
that commit a096813b got rid of?

Here's a failure in 031_recovery_conflict.pl that smells like
concurrent pread() corruption:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tadarida&dt=2022-05-16%2015%3A45%3A54

2022-05-16 18:10:33.375 CEST [52106:1] LOG: started streaming WAL
from primary at 0/3000000 on timeline 1
2022-05-16 18:10:33.621 CEST [52105:5] LOG: incorrect resource
manager data checksum in record at 0/338FDC8
2022-05-16 18:10:33.622 CEST [52106:2] FATAL: terminating walreceiver
process due to administrator command

Presumably we also need the has_wal_read_bug kludge in all these new
tests that use replication.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-05-17 00:05:44 Re: Minor improvements to test log navigability
Previous Message David Rowley 2022-05-16 23:26:04 Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)