ci: enable wal_consistency_checking in Linux Meson (64-bit) task

[NikolayS]

What

Enable wal_consistency_checking coverage in CI by extending PG_TEST_EXTRA for the Linux - Meson (64-bit) task, so src/test/recovery/t/027_stream_regress.pl turns on wal_consistency_checking = all on the primary.

Why

027_stream_regress runs the full regression suite through a streaming standby. It only enables WAL consistency checking when PG_TEST_EXTRA matches \bwal_consistency_checking\b (it's resource intensive, hence opt-in):

if (   $ENV{PG_TEST_EXTRA}
    && $ENV{PG_TEST_EXTRA} =~ m/\bwal_consistency_checking\b/)
{
    $node_primary->append_conf('postgresql.conf',
        'wal_consistency_checking = all');
}

No CI task set that value, so this check — which verifies WAL redo reconstructs byte-identical pages on a standby — had effectively zero coverage in CI. This is exactly the kind of bug (redo routine not matching the original page modification) that is otherwise very hard to catch.

Change

The change is scoped to the "Test world" step of a single Linux task, extending the workflow-level PG_TEST_EXTRA so the added cost stays contained:

      - name: Test world
        shell: *su_postgres_shell
        env:
          PG_TEST_EXTRA: ${{env.PG_TEST_EXTRA}} wal_consistency_checking
        run: *meson_test_world_cmd

Local validation

Built with meson setup build --buildtype=debug -Dcassert=true -Dtap_tests=enabled and ran 027_stream_regress as an unprivileged user:

Run	PG_TEST_EXTRA	Result	Wall-clock
Enabled	wal_consistency_checking	OK — 11 subtests passed (88.03s test time)	~89s
Baseline	(unset)	OK	~63s

Delta: roughly +26s (~+41%) for the single task — a modest cost for a heavily used replication code path. testwrap only falls back to the configure-time --pg-test-extra when PG_TEST_EXTRA is absent from the environment, so the workflow-level value flows through correctly.

Closes #69

🤖 Generated with Claude Code

https://claude.ai/code/session_01PtxA6B4d47ietk5dGsseuP

---

Generated by Claude Code