On Mon, 13 May 2024 at 16:13, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Matthias van de Meent <boekewurm+postg...@gmail.com> writes: > > PFA a patch that fixes this issue, by assuming that all pages in the > > source database utilize a non-standard page layout. > > Surely that cure is worse than the disease?
I don't know where we would get the information whether the selected relation fork's pages are standard-compliant. We could base it off of the fork number (that info is available locally) but that doesn't guarantee much. For VM and FSM-pages we know they're essentially never standard-compliant (hence this thread), but for the main fork it is anyone's guess once the user has installed an additional AM - which we don't detect nor pass through to the offending RelationCopyStorageUsingBuffer. As for "worse", the default template database is still much smaller than the working set of most databases. This will indeed regress the workload a bit, but only by the fraction of holes in the page + all FSM/VM data. I think the additional WAL volume during CREATE DATABASE is worth it when the alternative is losing that data with physical replication/secondary instances. Note that this does not disable page compression, it just stops the logging of holes in pages; holes which generally are only a fraction of the whole database. It's not inconceivable that this will significantly increase WAL volume, but I think we should go for correctness rather than fastest copy. If we went with fastest copy, we'd better just skip logging the FSM and VM forks because we're already ignoring the data of the pages, so why not ignore the pages themselves, too? I don't think that holds water when we want to be crash-proof in CREATE DATABASE, with a full data copy of the template database. Kind regards, Matthias van de Meent Neon (https://neon.tech)
