agora inbox for pgsql-committers@postgresql.org
help / color / mirror / Atom feedpgsql: Fix unlogged sequence corruption after standby promotion
6+ messages / 1 participants
[nested] [flat]
* pgsql: Fix unlogged sequence corruption after standby promotion
@ 2026-06-29 23:53 Fujii Masao <fujii@postgresql.org>
0 siblings, 0 replies; 6+ messages in thread
From: Fujii Masao @ 2026-06-29 23:53 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix unlogged sequence corruption after standby promotion
Previously, if an unlogged sequence was created on the primary and
replicated to a standby, reading the sequence after promoting the
standby (for example, with nextval()) could trigger the following
assertion failure:
TRAP: failed Assert("((const PageHeaderData *) page)->pd_special >= SizeOfPageHeaderData")
In non-assert builds, the same operation could instead fail with an
error such as:
ERROR: bad magic number in sequence
The problem was that seq_redo() updated the init fork page in shared
buffers but did not flush it to disk. During promotion,
ResetUnloggedRelations() recreates the main fork of unlogged
relations by copying the init fork from disk, bypassing shared
buffers. As a result, the main fork could be recreated from a stale
init fork instead of the WAL-replayed page.
Fix this by introducing a helper to flush init fork buffers
immediately, and make seq_redo() use it. As a result, the main fork
of an unlogged sequence is recreated from the up-to-date init fork on
disk, allowing the unlogged sequence to be read successfully after
standby promotion.
Backpatch to v15, where unlogged sequences were introduced.
Author: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: vignesh C <vignesh21@gmail.com>
Discussion: https://postgr.es/m/CAHGQGwH1Ssze3XM6wjoTjSLVOR041c6xP+vsdLP951=w8oG8bA@mail.gmail.com
Backpatch-through: 15
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/8e684ce11ddaac2604375b8efcae97f6b36af4e7
Modified Files
--------------
src/backend/access/hash/hash_xlog.c | 29 ++----------------
src/backend/access/transam/xlogutils.c | 26 ++++++++++++++++-
src/backend/commands/sequence_xlog.c | 1 +
src/include/access/xlogutils.h | 2 ++
src/test/recovery/meson.build | 1 +
.../recovery/t/054_unlogged_sequence_promotion.pl | 34 ++++++++++++++++++++++
6 files changed, 66 insertions(+), 27 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix unlogged sequence corruption after standby promotion
@ 2026-06-29 23:53 Fujii Masao <fujii@postgresql.org>
0 siblings, 0 replies; 6+ messages in thread
From: Fujii Masao @ 2026-06-29 23:53 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix unlogged sequence corruption after standby promotion
Previously, if an unlogged sequence was created on the primary and
replicated to a standby, reading the sequence after promoting the
standby (for example, with nextval()) could trigger the following
assertion failure:
TRAP: failed Assert("((const PageHeaderData *) page)->pd_special >= SizeOfPageHeaderData")
In non-assert builds, the same operation could instead fail with an
error such as:
ERROR: bad magic number in sequence
The problem was that seq_redo() updated the init fork page in shared
buffers but did not flush it to disk. During promotion,
ResetUnloggedRelations() recreates the main fork of unlogged
relations by copying the init fork from disk, bypassing shared
buffers. As a result, the main fork could be recreated from a stale
init fork instead of the WAL-replayed page.
Fix this by introducing a helper to flush init fork buffers
immediately, and make seq_redo() use it. As a result, the main fork
of an unlogged sequence is recreated from the up-to-date init fork on
disk, allowing the unlogged sequence to be read successfully after
standby promotion.
Backpatch to v15, where unlogged sequences were introduced.
Author: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: vignesh C <vignesh21@gmail.com>
Discussion: https://postgr.es/m/CAHGQGwH1Ssze3XM6wjoTjSLVOR041c6xP+vsdLP951=w8oG8bA@mail.gmail.com
Backpatch-through: 15
Branch
------
REL_19_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/22af34b983620a840e38c5f4ddae34b53647ba5c
Modified Files
--------------
src/backend/access/hash/hash_xlog.c | 29 ++----------------
src/backend/access/transam/xlogutils.c | 26 ++++++++++++++++-
src/backend/commands/sequence_xlog.c | 1 +
src/include/access/xlogutils.h | 2 ++
src/test/recovery/meson.build | 1 +
.../recovery/t/054_unlogged_sequence_promotion.pl | 34 ++++++++++++++++++++++
6 files changed, 66 insertions(+), 27 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix unlogged sequence corruption after standby promotion
@ 2026-06-29 23:54 Fujii Masao <fujii@postgresql.org>
0 siblings, 0 replies; 6+ messages in thread
From: Fujii Masao @ 2026-06-29 23:54 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix unlogged sequence corruption after standby promotion
Previously, if an unlogged sequence was created on the primary and
replicated to a standby, reading the sequence after promoting the
standby (for example, with nextval()) could trigger the following
assertion failure:
TRAP: failed Assert("((const PageHeaderData *) page)->pd_special >= SizeOfPageHeaderData")
In non-assert builds, the same operation could instead fail with an
error such as:
ERROR: bad magic number in sequence
The problem was that seq_redo() updated the init fork page in shared
buffers but did not flush it to disk. During promotion,
ResetUnloggedRelations() recreates the main fork of unlogged
relations by copying the init fork from disk, bypassing shared
buffers. As a result, the main fork could be recreated from a stale
init fork instead of the WAL-replayed page.
Fix this by introducing a helper to flush init fork buffers
immediately, and make seq_redo() use it. As a result, the main fork
of an unlogged sequence is recreated from the up-to-date init fork on
disk, allowing the unlogged sequence to be read successfully after
standby promotion.
Backpatch to v15, where unlogged sequences were introduced.
Author: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: vignesh C <vignesh21@gmail.com>
Discussion: https://postgr.es/m/CAHGQGwH1Ssze3XM6wjoTjSLVOR041c6xP+vsdLP951=w8oG8bA@mail.gmail.com
Backpatch-through: 15
Branch
------
REL_18_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/627605713074e51f29b623cd799e37a9f411c57b
Modified Files
--------------
src/backend/access/hash/hash_xlog.c | 29 ++----------------
src/backend/access/transam/xlogutils.c | 26 ++++++++++++++++-
src/backend/commands/sequence.c | 1 +
src/include/access/xlogutils.h | 2 ++
src/test/recovery/meson.build | 1 +
.../recovery/t/054_unlogged_sequence_promotion.pl | 34 ++++++++++++++++++++++
6 files changed, 66 insertions(+), 27 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix unlogged sequence corruption after standby promotion
@ 2026-06-29 23:54 Fujii Masao <fujii@postgresql.org>
0 siblings, 0 replies; 6+ messages in thread
From: Fujii Masao @ 2026-06-29 23:54 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix unlogged sequence corruption after standby promotion
Previously, if an unlogged sequence was created on the primary and
replicated to a standby, reading the sequence after promoting the
standby (for example, with nextval()) could trigger the following
assertion failure:
TRAP: failed Assert("((const PageHeaderData *) page)->pd_special >= SizeOfPageHeaderData")
In non-assert builds, the same operation could instead fail with an
error such as:
ERROR: bad magic number in sequence
The problem was that seq_redo() updated the init fork page in shared
buffers but did not flush it to disk. During promotion,
ResetUnloggedRelations() recreates the main fork of unlogged
relations by copying the init fork from disk, bypassing shared
buffers. As a result, the main fork could be recreated from a stale
init fork instead of the WAL-replayed page.
Fix this by introducing a helper to flush init fork buffers
immediately, and make seq_redo() use it. As a result, the main fork
of an unlogged sequence is recreated from the up-to-date init fork on
disk, allowing the unlogged sequence to be read successfully after
standby promotion.
Backpatch to v15, where unlogged sequences were introduced.
Author: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: vignesh C <vignesh21@gmail.com>
Discussion: https://postgr.es/m/CAHGQGwH1Ssze3XM6wjoTjSLVOR041c6xP+vsdLP951=w8oG8bA@mail.gmail.com
Backpatch-through: 15
Branch
------
REL_17_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/a1ed6a9a031af5d945dee498ba364cddea7af59f
Modified Files
--------------
src/backend/access/hash/hash_xlog.c | 29 ++----------------
src/backend/access/transam/xlogutils.c | 26 ++++++++++++++++-
src/backend/commands/sequence.c | 1 +
src/include/access/xlogutils.h | 2 ++
src/test/recovery/meson.build | 1 +
.../recovery/t/054_unlogged_sequence_promotion.pl | 34 ++++++++++++++++++++++
6 files changed, 66 insertions(+), 27 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix unlogged sequence corruption after standby promotion
@ 2026-06-29 23:54 Fujii Masao <fujii@postgresql.org>
0 siblings, 0 replies; 6+ messages in thread
From: Fujii Masao @ 2026-06-29 23:54 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix unlogged sequence corruption after standby promotion
Previously, if an unlogged sequence was created on the primary and
replicated to a standby, reading the sequence after promoting the
standby (for example, with nextval()) could trigger the following
assertion failure:
TRAP: failed Assert("((const PageHeaderData *) page)->pd_special >= SizeOfPageHeaderData")
In non-assert builds, the same operation could instead fail with an
error such as:
ERROR: bad magic number in sequence
The problem was that seq_redo() updated the init fork page in shared
buffers but did not flush it to disk. During promotion,
ResetUnloggedRelations() recreates the main fork of unlogged
relations by copying the init fork from disk, bypassing shared
buffers. As a result, the main fork could be recreated from a stale
init fork instead of the WAL-replayed page.
Fix this by introducing a helper to flush init fork buffers
immediately, and make seq_redo() use it. As a result, the main fork
of an unlogged sequence is recreated from the up-to-date init fork on
disk, allowing the unlogged sequence to be read successfully after
standby promotion.
Backpatch to v15, where unlogged sequences were introduced.
Author: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: vignesh C <vignesh21@gmail.com>
Discussion: https://postgr.es/m/CAHGQGwH1Ssze3XM6wjoTjSLVOR041c6xP+vsdLP951=w8oG8bA@mail.gmail.com
Backpatch-through: 15
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/913d3b610ccdebe16178300327d0ba63d27d88a4
Modified Files
--------------
src/backend/access/hash/hash_xlog.c | 29 ++----------------
src/backend/access/transam/xlogutils.c | 26 ++++++++++++++++-
src/backend/commands/sequence.c | 1 +
src/include/access/xlogutils.h | 2 ++
src/test/recovery/meson.build | 1 +
.../recovery/t/054_unlogged_sequence_promotion.pl | 34 ++++++++++++++++++++++
6 files changed, 66 insertions(+), 27 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix unlogged sequence corruption after standby promotion
@ 2026-06-29 23:54 Fujii Masao <fujii@postgresql.org>
0 siblings, 0 replies; 6+ messages in thread
From: Fujii Masao @ 2026-06-29 23:54 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix unlogged sequence corruption after standby promotion
Previously, if an unlogged sequence was created on the primary and
replicated to a standby, reading the sequence after promoting the
standby (for example, with nextval()) could trigger the following
assertion failure:
TRAP: failed Assert("((const PageHeaderData *) page)->pd_special >= SizeOfPageHeaderData")
In non-assert builds, the same operation could instead fail with an
error such as:
ERROR: bad magic number in sequence
The problem was that seq_redo() updated the init fork page in shared
buffers but did not flush it to disk. During promotion,
ResetUnloggedRelations() recreates the main fork of unlogged
relations by copying the init fork from disk, bypassing shared
buffers. As a result, the main fork could be recreated from a stale
init fork instead of the WAL-replayed page.
Fix this by introducing a helper to flush init fork buffers
immediately, and make seq_redo() use it. As a result, the main fork
of an unlogged sequence is recreated from the up-to-date init fork on
disk, allowing the unlogged sequence to be read successfully after
standby promotion.
Backpatch to v15, where unlogged sequences were introduced.
Author: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: vignesh C <vignesh21@gmail.com>
Discussion: https://postgr.es/m/CAHGQGwH1Ssze3XM6wjoTjSLVOR041c6xP+vsdLP951=w8oG8bA@mail.gmail.com
Backpatch-through: 15
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/d2980067bc3bcf44769cccbbdafb4e37099c890d
Modified Files
--------------
src/backend/access/hash/hash_xlog.c | 29 ++---------------
src/backend/access/transam/xlogutils.c | 26 +++++++++++++++-
src/backend/commands/sequence.c | 1 +
src/include/access/xlogutils.h | 2 ++
.../recovery/t/054_unlogged_sequence_promotion.pl | 36 ++++++++++++++++++++++
5 files changed, 67 insertions(+), 27 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-06-29 23:54 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-06-29 23:53 pgsql: Fix unlogged sequence corruption after standby promotion Fujii Masao <fujii@postgresql.org>
2026-06-29 23:53 pgsql: Fix unlogged sequence corruption after standby promotion Fujii Masao <fujii@postgresql.org>
2026-06-29 23:54 pgsql: Fix unlogged sequence corruption after standby promotion Fujii Masao <fujii@postgresql.org>
2026-06-29 23:54 pgsql: Fix unlogged sequence corruption after standby promotion Fujii Masao <fujii@postgresql.org>
2026-06-29 23:54 pgsql: Fix unlogged sequence corruption after standby promotion Fujii Masao <fujii@postgresql.org>
2026-06-29 23:54 pgsql: Fix unlogged sequence corruption after standby promotion Fujii Masao <fujii@postgresql.org>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox