Re: BUG #16866: pg_basebackup Windows Server 2016
От | Ivan Salvato |
---|---|
Тема | Re: BUG #16866: pg_basebackup Windows Server 2016 |
Дата | |
Msg-id | B5D9591D-7C5C-4863-ACBE-1A61D2E81DC2@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #16866: pg_basebackup Windows Server 2016 (Michael Paquier <michael@paquier.xyz>) |
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: