Horton

Re: PG 14 release notes, first draft

Tatsuo Ishii <ishii@sraoss.co.jp>

View thread View on postgr.es
From: Tatsuo Ishii <ishii@sraoss.co.jp>
To: sawada.mshk@gmail.com
Cc: bruce@momjian.us, michael@paquier.xyz, pgsql-hackers@postgresql.org
Date: 2021-06-21T05:47:16Z
Lists: pgsql-hackers

Attachments

> On Mon, Jun 21, 2021 at 12:50 PM Bruce Momjian <bruce@momjian.us> wrote:
>>
>> 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.
> 
> Thanks!
> 
> I got the parse error after applying the patch:
> 
> release-14.sgml:3562: parser error : Input is not proper UTF-8,
> indicate encoding !
> Bytes: 0xE9 0x20 0x53 0x61
>         (Juan Jos Santamara Flecha)
>                  ^
> 
> Is that a problem with my environment?

Me too. I think the problem is, Bruce's patch is encoded in
ISO-8859-1, not UTF-8. As far as I know PostgreSQL never encodes
*.sgml files in ISO-8859-1. Anyway, attached is the Bruce's patch
encoded in UTF-8. This works for me.

My guess is, when Bruce attached the file, his MUA automatically
changed the file encoding from UTF-8 to ISO-8859-1 (it could happen in
many MUA). Also that's the reason why he does not see the problem
while compiling the sgml files. In his environment release-14.sgml is
encoded in UTF-8, I guess. To prevent the problem next time, it's
better to change the mime type of the attached file to
Application/Octet-Stream.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

Commits

  1. doc: add mention of +4GB windows file handling in PG14 relnotes

  2. doc: PG 14 relnotes fixes

  3. doc: PG 14 relnote updates

  4. doc: PG 14 relnotes, adjust pg_{read|write}_all_data entry

  5. Update PG 14 relnotes for vacuum_cost_page_miss

  6. doc: update PG 14 release notes with recent feedback

  7. Update replication statistics after every stream/spill.

  8. Add information of total data processed to replication slot stats.

  9. Use NameData datatype for slotname in stats.

  10. Add back vacuum_cleanup_index_scale_factor parameter.

  11. Don't consider newly inserted tuples in nbtree VACUUM.

  12. pgbench: Improve time logic.

  13. Track total amounts of times spent writing and syncing WAL data to disk.

  14. Allow decoding at prepare time in ReorderBuffer.

  15. Extend the output plugin API to allow decoding of prepared xacts.

  16. Fix nbtree cleanup-only VACUUM stats inaccuracies.

  17. Execute invalidation messages for each XLOG_XACT_INVALIDATIONS message

  18. Fix our Windows stat() emulation to handle file sizes > 4GB.

  19. Trigger autovacuum based on number of INSERTs

  20. Speed up planning when partitions can be pruned at plan time.

  21. Remove support for password_encryption='off' / 'plain'.

  22. Increase work_mem and maintenance_work_mem defaults by 4x