From: | Ivan Salvato <ivan(dot)salvato(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16866: pg_basebackup Windows Server 2016 |
Date: | 2021-02-16 07:07:21 |
Message-ID: | B5D9591D-7C5C-4863-ACBE-1A61D2E81DC2@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Thank you very much for your reply
Best Regards
Ivan
> On 16 Feb 2021, at 02:00, Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Nüscheler | 2021-02-16 08:25:34 | Re: BUG #16865: Regression: GIN Negated prefix search returns results that contain the search term |
Previous Message | PG Bug reporting form | 2021-02-16 06:45:29 | BUG #16869: GROUP BY on primary key unnecessarily triggers a full table scan |