Re: BUG #16866: pg_basebackup Windows Server 2016
От | Michael Paquier |
---|---|
Тема | Re: BUG #16866: pg_basebackup Windows Server 2016 |
Дата | |
Msg-id | YCsZIX2A2Ilsvfnl@paquier.xyz обсуждение исходный текст |
Ответ на | BUG #16866: pg_basebackup Windows Server 2016 (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #16866: pg_basebackup Windows Server 2016
|
Список | pgsql-bugs |
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
Вложения
В списке pgsql-bugs по дате отправления: