WAL_LOG CREATE DATABASE strategy broken for non-standard page layouts
Matthias van de Meent <boekewurm+postgres@gmail.com>
From: Matthias van de Meent <boekewurm+postgres@gmail.com>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Robert Haas <robertmhaas@gmail.com>
Date: 2024-05-13T12:31:41Z
Lists: pgsql-hackers
Attachments
- v1-0001-Fix-logging-of-non-standard-pages-in-RelationCopy.patch (application/octet-stream) patch v1-0001
Hi, My collegue Konstantin Knizhnik pointed out that we fail to mark pages with a non-standard page layout with page_std=false in RelationCopyStorageUsingBuffer when we WAL-log them. This causes us to interpret the registered buffer as a standard buffer, and omit the hole in the page, which for FSM/VM pages covers the whole page. The immediate effect of this bug is that replicas and primaries in a physical replication system won't have the same data in their VM- and FSM-forks until the first VACUUM on the new database has WAL-logged these pages again. Whilst not actively harmful for the VM/FSM subsystems, it's definitely suboptimal. Secondary unwanted effects are that AMs that use the buffercache- but which don't use or update the pageheader- also won't see the main data logged in WAL, thus potentially losing user data in the physical replication stream or with a system crash. I've not looked for any such AMs and am unaware of any that would have this issue, but it's better to fix this. PFA a patch that fixes this issue, by assuming that all pages in the source database utilize a non-standard page layout. Kind regards, Matthias van de Meent Neon (https://neon.tech)