[Bug] Mirrors crash during WAL replay when wal_compression is pglz/lz4
Los mantenedores suelen responder en 3 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- Medio día
- Aptitud para principiantes
- 58/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Área
- databases, distributed-systems
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- C
- Estrellas
- 1.4k
- Forks
- 262
- Merge medio
- 4 d 20 h
- PR fusionados (30 d)
- 57
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de apache/cloudberry
-
[Bug] Expand fails to recognize user-defined tablespacesPosiblemente ocupada @nix-oss la tomó hace 59 días. Abiertotype: Bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
apache/cloudberry#1885 · 2 reacciones ·
Los mantenedores suelen responder en 3 días
-
gpexpand first stage fails: 'SyncPackages' object has no attribute 'ret' (extension sync never runs; regression)Posiblemente ocupada @talmacschen-arch la tomó hace 120 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
apache/cloudberry#1825 ·
Los mantenedores suelen responder en 3 días
-
Lance support: contrib/lance_fdw and the MCP server's Lance toolsPosiblemente ocupada @MisterRaindrop la tomó hace 1 día. Abierto
apache/cloudberry#2139 · 1 asignado ·
Los mantenedores suelen responder en 3 días
-
type: Proposal
Dificultad 4/5 3-5 días Aptitud para principiantes 22/100
apache/cloudberry#2136 · 1 comentario ·
Los mantenedores suelen responder en 3 días
-
type: Bug
Dificultad 4/5 3-5 días Aptitud para principiantes 30/100
apache/cloudberry#2135 · 1 comentario ·
Los mantenedores suelen responder en 3 días
Todos los issues de apache/cloudberry
Issues similares
-
backlog bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
EchoTools/nevr-runtime#653 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
InfiniTimeOrg/InfiniTime#2492 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 80/100
Los mantenedores suelen responder en 1 día
-
system: coco
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
FujiNetWIFI/fujinet-config#274 ·
Los mantenedores suelen responder en 1 día
-
base-files: 82_config_generate: regenerate /etc/board.json if 0-bytes / truncated after power cutAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
openwrt/openwrt#25940 · 5 comentarios ·
Los mantenedores suelen responder en 1 día