From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PG 14 release notes, first draft |
Date: | 2021-06-15 03:01:00 |
Message-ID: | YMgX7Mqv/Ogo4i4y@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 15, 2021 at 11:49:21AM +0900, Masahiko Sawada wrote:
> On Tue, Jun 15, 2021 at 10:36 AM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> OK, but I need more information on how users will see a difference based
>> on this commit:
+1. That would be good to have in the release notes.
> I think that since with this commit the server on Windows can handle a
> file over 4GB, COPY FROM loading data from an over 4GB file and
> pg_dump dumping a large table work now.
Segment files or WAL files larger than 4GB also gain from that.
Anything for which we may finish to do a stat() on benefits from this
change if running on Windows. For pg_dump, a workaround in PG <= 13
was to use --no-sync as the stat() failure came from files with a size
larger than 4GB. That's rather sad as that means sacrifying
durability for more usability :(
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2021-06-15 03:42:06 | Re: Different compression methods for FPI |
Previous Message | Tom Lane | 2021-06-15 02:57:08 | Improving the isolationtester: fewer failures, less delay |