diff options
author | Michael Paquier <michael@paquier.xyz> | 2023-02-22 10:14:52 +0900 |
---|---|---|
committer | Michael Paquier <michael@paquier.xyz> | 2023-02-22 10:14:52 +0900 |
commit | 8a8661828ae14e4d3b6beac5e8d8b37bd4e79004 (patch) | |
tree | 560fae46ba540a62f7e7175230375178d2d86d5f /src/backend/executor/nodeModifyTable.c | |
parent | b3e184a5d4fdbc43d2cb99865ea2e073c09b9584 (diff) | |
download | postgresql-8a8661828ae14e4d3b6beac5e8d8b37bd4e79004.tar.gz postgresql-8a8661828ae14e4d3b6beac5e8d8b37bd4e79004.zip |
Fix corruption of templates after CREATE DATABASE .. STRATEGY WAL_LOG
WAL_LOG does a scan of the template's pg_class to determine the set of
relations that need to be copied from a template database to the new
one. However, as coded in 9c08aea, this copy strategy would load the
pages of pg_class without considering it as a permanent relation,
causing the loaded pages to never be flushed when they should. Any
modification of the template's pg_class, mostly through DDLs, would then
be missed, causing corruptions.
STRATEGY = WAL_LOG is the default over FILE_COPY since it has been
introduced, so any changes done to pg_class on a database template would
be gone. Updates of database templates should be a rare thing, so the
impact of this bug should be hopefully limited. The pre-14 default
strategy FILE_COPY is safe, and can be used as a workaround.
Ryo Matsumura has found and analyzed the issue, and Nathan has written a
test able to reproduce the failure (with few tweaks from me).
Backpatch down to 15, where STRATEGY = WAL_LOG has been introduced.
Author: Nathan Bossart, Ryo Matsumura
Reviewed-by: Dilip Kumar, Michael Paquier
Discussion: https://postgr.es/m/TYCPR01MB6868677E499C9AD5123084B5E8A39@TYCPR01MB6868.jpnprd01.prod.outlook.com
Backpatch-through: 15
Diffstat (limited to 'src/backend/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions