Обсуждение: BUG #16866: pg_basebackup Windows Server 2016
The following bug has been logged on the website: Bug reference: 16866 Logged by: Ivan Salvato Email address: ivan.salvato@gmail.com PostgreSQL version: 12.0 Operating system: windows Description: Scenario - vm Windows Server 2016 - PostgreSQL 12 (configurated wal_level = archive; archive_mode = on; archive_command = 'copy "%p" "W:\\POSTGRES\\pg_log_archive\\%f" ') - db 122 GB - backup full of PostgreSQL with pg_basebackup (parameters -Ft -z) folder W:\pg_backup. We delete the replicated transaction logs with pg_archivecleanup in W:\pg_log_archive Problem: backup fails when the base.tar.gz achieve di 4 GB with pg_basebackup: error: could not stat file "W:\POSTGRES\pg_backup\Base-Backup_2021-02-05_103921/base.tar.gz": Unknown error. When we used Postgresql 9.6 it worked correctly. Thanks in advance
On Mon, Feb 15, 2021 at 03:12:10PM +0000, PG Bug reporting form wrote: > Problem: > backup fails when the base.tar.gz achieve di 4 GB with pg_basebackup: error: > could not stat file > "W:\POSTGRES\pg_backup\Base-Backup_2021-02-05_103921/base.tar.gz": Unknown > error. This comes from the fact that Windows stat() is not able to handle files larger than 4GB by design, and the fact that pg_basebackup tries to make durable all the contents of a base backup when it is done streaming something on the target host. I bet that the failure you are seeing is the fsync() part for base.tar.gz. You can bypass that by using --no-sync as option, which would basically emulate what Postgres <= 9.6 is doing. In Postgres 14, the emulation of stat() has been fixed to handle the case of files larger than 4GB: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=bed90759fcbcd72d4d06969eebab81e47326f9a2 This is arguably a bugfix, so we may consider a backpatch in the future, but knowing how invasive the fix is we are still in a phase where we want to have some dust settle on this change and Windows has its own way to do weird things all the time. IMO, It may be better to revisit that a couple of months after 14 is released so as there is some feedback from the field with this change. -- Michael
Вложения
Thank you very much for your reply Best Regards Ivan > On 16 Feb 2021, at 02:00, Michael Paquier <michael@paquier.xyz> wrote: > > On Mon, Feb 15, 2021 at 03:12:10PM +0000, PG Bug reporting form wrote: >> Problem: >> backup fails when the base.tar.gz achieve di 4 GB with pg_basebackup: error: >> could not stat file >> "W:\POSTGRES\pg_backup\Base-Backup_2021-02-05_103921/base.tar.gz": Unknown >> error. > > This comes from the fact that Windows stat() is not able to handle > files larger than 4GB by design, and the fact that pg_basebackup tries > to make durable all the contents of a base backup when it is done > streaming something on the target host. I bet that the failure you > are seeing is the fsync() part for base.tar.gz. > > You can bypass that by using --no-sync as option, which would > basically emulate what Postgres <= 9.6 is doing. In Postgres 14, the > emulation of stat() has been fixed to handle the case of files larger > than 4GB: > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=bed90759fcbcd72d4d06969eebab81e47326f9a2 > > This is arguably a bugfix, so we may consider a backpatch in the > future, but knowing how invasive the fix is we are still in a phase > where we want to have some dust settle on this change and Windows has > its own way to do weird things all the time. IMO, It may be better to > revisit that a couple of months after 14 is released so as there is > some feedback from the field with this change. > -- > Michael