Re: PG 14 release notes, first draft - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: PG 14 release notes, first draft
Date
Msg-id 20210621035021.GA22121@momjian.us
Whole thread Raw
In response to Re: PG 14 release notes, first draft  (Michael Paquier <michael@paquier.xyz>)
Responses Re: PG 14 release notes, first draft
List pgsql-hackers
On Tue, Jun 15, 2021 at 12:01:00PM +0900, Michael Paquier wrote:
> 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@momjian.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 :(

OK, I went with this text and put it in the Source Code section since it
applies to several layers of Postgres.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.


Attachment

pgsql-hackers by date:

Previous
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: locking [user] catalog tables vs 2pc vs logical rep
Next
From: Masahiko Sawada
Date:
Subject: Re: Optionally automatically disable logical replication subscriptions on error