On 3/25/24 15:31, Robert Haas wrote: > On Sat, Mar 23, 2024 at 9:37 AM Tomas Vondra > <tomas.von...@enterprisedb.com> wrote: >> OK, that makes sense. Here's a patch that should work like this - in >> copy_file we check if we need to calculate checksums, and either use the >> requested copy method, or fall back to the block-by-block copy. > > + Use efficient file cloning (also known as <quote>reflinks</quote> on > + some systems) instead of copying files to the new cluster. This can > > new cluster -> output directory >
Ooops, forgot to fix this. Will do in next version. > I think your version kind of messes up the debug logging. In my > version, every call to copy_file() would emit either "would copy > \"%s\" to \"%s\" using strategy %s" and "copying \"%s\" to \"%s\" > using strategy %s". In your version, the dry_run mode emits a string > similar to the former, but creates separate translatable strings for > each copy method instead of using the same one with a different value > of %s. In non-dry-run mode, I think your version loses the debug > logging altogether. > Yeah. Sorry for not being careful enough about that, I was focusing on the actual copy logic and forgot about this. The patch I shared a couple minutes ago should fix this, effectively restoring the original debug behavior. I liked the approach with calling strategy_implementation a bit more, I wonder if it'd be better to go back to that for the "accelerated" copy methods, somehow. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
