Re: WAL_LOG CREATE DATABASE strategy broken for non-standard page layouts
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-05-13T19:43:24Z
Lists: pgsql-hackers
On Mon, May 13, 2024 at 10:53 AM Matthias van de Meent <boekewurm+postgres@gmail.com> wrote: > It's not inconceivable that this will significantly increase WAL > volume, but I think we should go for correctness rather than fastest > copy. I don't think we can afford to just do this blindly for the sake of a hypothetical non-core AM that uses nonstandard pages. There must be lots of cases where the holes are large, and where the WAL volume would be a multiple of what it is currently. That's a *big* regression. > 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. This seems like a red herring. Either assuming standard pages is a good idea or it isn't, and either logging the FSM and VM forks is a good idea or it isn't, but those are two separate questions. -- Robert Haas EDB: http://www.enterprisedb.com