[Bug] Mirrors crash during WAL replay when wal_compression is pglz/lz4
メンテナーはふだん 3 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 半日
- 初心者へのやさしさ
- 58/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
調査の方向性
Start in RestoreBlockImage() in src/backend/access/transam/xlogreader.c (around line 2096), where zstd_decompress_backupblock() runs before the bimg_info method check. Compare it with XLogCompressBackupBlock() on the write side to see which methods write images. Done when pglz and lz4 images replay without error; reproduce with the SQL in the issue on a cluster with mirrors.
索引モデルが issue の本文から書いたものです。
説明
Apache Cloudberry version
No response
What happened
Reproduce (on a cluster with mirrors):
CREATE TABLE w (a int, b text) DISTRIBUTED BY (a);
INSERT INTO w SELECT i, repeat('x', 100) FROM generate_series(1, 1000) i;
CHECKPOINT;
SET wal_compression = pglz;
UPDATE w SET b = 'y' WHERE a < 100;
Actual: the UPDATE succeeds, but all segment mirrors stop WAL replay and shut down, and FTS marks them down:
FATAL: invalid compressed image at 0/C7CFF070, block 0 (error computing decompression size)
LOG: startup process (PID ...) exited with exit code 1
LOG: shutting down due to startup process failure
gprecoverseg (incremental) reports success, but the mirrors replay the same WAL record and crash again. Only gprecoverseg -F (full recovery) brings them back.
Expected: the mirrors replay the WAL normally, as they do with SET wal_compression = zstd. With zstd, the same steps produce no errors.
Cause: in RestoreBlockImage() (src/backend/access/transam/xlogreader.c, around line 2096), every compressed page image is passed to zstd_decompress_backupblock() before the code checks bimg_info for the method
actually used. That zstd-only call dates from commit 60915ec6b2e ("Use zstd for wal_compression", 2020), when Greenplum always compressed WAL with zstd. Since the merges from PostgreSQL,
XLogCompressBackupBlock() writes images with the method chosen by wal_compression (pglz, lz4 or zstd), so pglz and lz4 images reach the zstd decoder and fail. A likely fix is to remove the unconditional zstd
call and rely on the per-method code that follows it.
Impact:
- A session-level SET wal_compression plus an ordinary write is enough. It leaves the cluster without mirror protection until an administrator runs a full recovery.
- Not verified: lz4 (expected to fail the same way, since the same code runs first), and whether a primary's own crash recovery also fails after replaying such a record.
What you think should happen instead
No response
How to reproduce
Reproduce (on a cluster with mirrors):
CREATE TABLE w (a int, b text) DISTRIBUTED BY (a);
INSERT INTO w SELECT i, repeat('x', 100) FROM generate_series(1, 1000) i;
CHECKPOINT;
SET wal_compression = pglz;
UPDATE w SET b = 'y' WHERE a < 100;
Operating System
any
Anything else
No response
Are you willing to submit PR?
- Yes, I am willing to submit a PR!
Code of Conduct
- I agree to follow this project's Code of Conduct.
- 主要言語
- C
- スター
- 1.4k
- フォーク
- 262
- 平均マージ
- 4日 20時間
- マージ済み PR(30日)
- 57
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
apache/cloudberry のほかの issue
-
[Bug] Expand fails to recognize user-defined tablespaces対応中かも @nix-oss が 61 日前に担当しました。 オープンtype: Bug
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
apache/cloudberry#1885 · リアクション 2 件 ·
メンテナーはふだん 3 日以内に返信
-
gpexpand first stage fails: 'SyncPackages' object has no attribute 'ret' (extension sync never runs; regression)対応中かも @talmacschen-arch が 122 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
apache/cloudberry#1825 ·
メンテナーはふだん 3 日以内に返信
-
Lance support: contrib/lance_fdw and the MCP server's Lance tools対応中かも @MisterRaindrop が 3 日前に担当しました。 オープン
apache/cloudberry#2139 · コメント 1 件 · 担当者 1 名 ·
メンテナーはふだん 3 日以内に返信
-
[Proposal] Remove `gpcontrib/gpmapreduce` starting from Cloudberry 3.0対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンtype: Proposal
難易度 4/5 3〜5日 初心者へのやさしさ 22/100
apache/cloudberry#2136 · コメント 1 件 ·
メンテナーはふだん 3 日以内に返信
-
type: Bug
難易度 4/5 3〜5日 初心者へのやさしさ 30/100
apache/cloudberry#2135 · コメント 1 件 ·
メンテナーはふだん 3 日以内に返信
apache/cloudberry の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
vercel-labs/zerolang#442 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 1 日以内に返信
-
triage
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
メンテナーはふだん 1 日以内に返信
-
mewencode: base256[] and base128[] are indexed out of bounds by a non-ASCII octet対応中かも @kazu-yamamoto が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
kazu-yamamoto/Mew#276 ·
メンテナーはふだん 1 日以内に返信
-
[iwm] transaction_get() copies the whole payload regardless of the length asked for対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 91/100
FujiNetWIFI/fujinet-firmware#2045 ·
メンテナーはふだん 1 日以内に返信