Subject: First draft of PG 17 release notes

From: Bruce Momjian <[email-masked]>
Date: Thu, 9 May 2024 00:03:50 -0400

I have committed the first draft of the PG 17 release notes;  you can
see the results here:

	https://momjian.us/pgsql_docs/release-17.html

It will be improved until the final release.  The item count is 188,
which is similar to recent releases:

	release-10:  189
	release-11:  170
	release-12:  180
	release-13:  178
	release-14:  220
	release-15:  184
	release-16:  206
	release-17:  188

I welcome feedback.  For some reason it was an easier job than usual.

-- 
  Bruce Momjian  <[email-masked]>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.

---

From: David Rowley <[email-masked]>
Date: Thu, 9 May 2024 16:44:47 +1200

> I welcome feedback.  For some reason it was an easier job than usual.

Thanks for working on that.

> +2023-11-02 [cac169d68] Increase DEFAULT_FDW_TUPLE_COST from 0.01 to 0.2

> +Double the default foreign data wrapper tuple cost (David Rowley, Umair Shahid)

That's 20x rather than 2x.

David

---

From: Muhammad Ikram <[email-masked]>
Date: Thu, 9 May 2024 09:47:34 +0500

Hi Bruce,

A minor formatting issue in the start below. Bullet is not required here.

E.1.1. Overview
<https://momjian.us/pgsql_docs/release-17.html#RELEASE-17-HIGHLIGHTS>

PostgreSQL 17 contains many new features and enhancements, including:

   -

The above items and other new features of PostgreSQL 17 are explained in
more detail in the sections below.
Regards,
Ikram

-- 
Muhammad Ikram

---

From: David Rowley <[email-masked]>
Date: Thu, 9 May 2024 16:52:14 +1200

> A minor formatting issue in the start below. Bullet is not required here.

This is a placeholder for the highlight features of v17 will go.
Bruce tends not to decide what those are all by himself.

David

---

From: Bertrand Drouvot <[email-masked]>
Date: Thu, 9 May 2024 04:53:38 +0000

Hi,

> 	https://momjian.us/pgsql_docs/release-17.html

Thanks for working on that!
 
> I welcome feedback.

> Add system view pg_wait_events that reports wait event types (Michael Paquier) 

Michael is the committer for 1e68e43d3f, the author is me.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

---

From: Masahiko Sawada <[email-masked]>
Date: Thu, 9 May 2024 14:17:12 +0900

Hi,

>         https://momjian.us/pgsql_docs/release-17.html

Thank you for working on that!

I'd like to mention some of my works. I think we can add the vacuum
performance improvements by the following commits:

- Add template for adaptive radix tree (ee1b30f1)
- Add TIDStore, to store sets of TIDs (ItemPointerData) efficiently (30e144287)
- Use TidStore for dead tuple TIDs storage during lazy vacuum (667e65aac)

Also, please consider the following item:

- Improve eviction algorithm in ReorderBuffer using max-heap for many
subtransactions (5bec1d6bc)

Finally, should we mention the following commit in the release note?
It's not a user-visible change but added a new regression test module.

- Add tests for XID wraparound (e255b646a)

Regards,

-- 
Masahiko Sawada

---

From: Richard Guo <[email-masked]>
Date: Thu, 9 May 2024 14:37:57 +0800

For this item:

> Allow the optimizer to improve CTE plans by using the sort order of
> columns referenced in earlier CTE clauses (Jian Guo)

I think you mean a65724dfa.  The author should be 'Richard Guo'.

And I'm wondering if it is more accurate to state it as "Allow the
optimizer to improve plans for the outer query by leveraging the sort
order of a CTE's output."

I think maybe a similar revision can be applied to the item just above
this one.

Thanks
Richard

---

From: Aleksander Alekseev <[email-masked]>
Date: Thu, 9 May 2024 12:18:44 +0300

Hi,

> which is similar to recent releases:

Thanks for working on this.

I believe the part of the 64-bit XIDs patchset that was delivered in
PG17 is worth highlighting in "E.1.3.10. Source Code" section:

4ed8f0913bfd
2cdf131c46e6
5a1dfde8334b
a60b8a58f435

All this can probably be summarized as one bullet "Index SLRUs by
64-bit integers rather than by 32-bit ones" where the authors are:
Maxim Orlov, Aleksander Alekseev, Alexander Korotkov, Teodor Sigaev,
Nikita Glukhov, Pavel Borisov, Yura Sokolov.

-- 
Best regards,
Aleksander Alekseev

---

From: jian he <[email-masked]>
Date: Thu, 9 May 2024 18:00:24 +0800

>         https://momjian.us/pgsql_docs/release-17.html

another potential incompatibilities issue:
ALTER TABLE DROP PRIMARY KEY

see:
https://www.postgresql.org/message-id/202404181849.6frtmajobe27%40alvherre.pgsql

---

From: Dagfinn Ilmari Mannsåker <[email-masked]>
Date: Thu, 09 May 2024 11:22:06 +0100

> 	https://momjian.us/pgsql_docs/release-17.html

My name is listed twice in the "Improve psql tab completion" item.

- ilmari

---

From: Dagfinn Ilmari Mannsåker <[email-masked]>
Date: Thu, 09 May 2024 11:31:17 +0100

> My name is listed twice in the "Improve psql tab completion" item.

You can move one of them to "Track DEALLOCATE in pg_stat_statements",
which Michael and I co-authored.

- ilmari

---

From: jian he <[email-masked]>
Date: Thu, 9 May 2024 18:53:30 +0800

>         https://momjian.us/pgsql_docs/release-17.html

* Add function pg_buffercache_evict() to allow shared buffer eviction
(Palak Chaturvedi, Thomas Munro)
* This is useful for testing.

this should put it on the section
< E.1.3.11. Additional Modules
?

Then I found out official release notes don't have <section> attributes,
so it doesn't matter?

<<
Allow ALTER OPERATOR to set more optimization attributes (Tommy Pavlicek)
This is useful for extensions.
<<
I think this commit title "Add hash support functions and hash opclass
for contrib/ltree."
 from [1] is more descriptive.
i am not 100% sure of the meaning of "This is useful for extensions."

[1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=485f0aa85995340fb62113448c992ee48dc6fff1

---

From: jian he <[email-masked]>
Date: Thu, 9 May 2024 18:57:01 +0800

> This is useful for extensions.

sorry,  I mean
<<
Allow the creation of hash indexes on ltree columns (Tommy Pavlicek)
This also enables hash join and hash aggregation on ltree columns.
<<

better description would be:
<<
Add hash support functions and hash opclass for contrib/ltree (Tommy Pavlicek)
This also enables hash join and hash aggregation on ltree columns.
<<

---

From: jian he <[email-masked]>
Date: Thu, 9 May 2024 19:49:55 +0800

> >         https://momjian.us/pgsql_docs/release-17.html

< Add columns to pg_stats to report range histogram information (Egor
Rogov, Soumyadeep Chakraborty)
I think this applies to range type and multi range type, "range
histogram information" seems not very clear to me.
So maybe:
< Add columns to pg_stats to report range-type histogram information
(Egor Rogov, Soumyadeep Chakraborty)

Display length and bounds histograms in pg_stats
< Add new COPY option "ON_ERROR ignore" to discard error rows (Damir
Belyalov, Atsushi Torikoshi, Alex Shulgin, Jian He, Jian He, Yugo
Nagata)
duplicate name.

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 9 May 2024 09:08:52 -0400

> That's 20x rather than 2x.

Oops, changed to:

	Increase the default foreign data wrapper tuple cost (David
	Rowley, Umair Shahid)

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 9 May 2024 09:10:16 -0400

On Thu, May  9, 2024 at 09:47:34AM +0500, Muhammad Ikram wrote:
>   • 
> The above items and other new features of PostgreSQL 17 are explained in more
> detail in the sections below.

That is just a place-holder.  I changed the bullet text to be:

	TO BE COMPLETED LATER

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 9 May 2024 09:11:10 -0400

> Bruce tends not to decide what those are all by himself.

Yes, I already have so much of my opinion in the release notes that I
prefer others to make that list, and to make the Acknowledgments list
at the bottom.

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 9 May 2024 09:29:21 -0400

> Michael is the committer for 1e68e43d3f, the author is me.

Wow, thank you for finding that.  The commit message is very clear so I
don't know how I made that mistake.  Fixed.

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 9 May 2024 09:48:41 -0400

> - Use TidStore for dead tuple TIDs storage during lazy vacuum (667e65aac)

Okay, I reworded the item, added authors, and added the commits:

	<!--
	Author: John Naylor <[email-masked]>
	2024-03-07 [ee1b30f12] Add template for adaptive radix tree
	Author: Masahiko Sawada <[email-masked]>
	2024-03-21 [30e144287] Add TIDStore, to store sets of TIDs (ItemPointerData) ef
	Author: Masahiko Sawada <[email-masked]>
	2024-04-02 [667e65aac] Use TidStore for dead tuple TIDs storage during lazy vac
	Author: Heikki Linnakangas <[email-masked]>
	2024-04-03 [6dbb49026] Combine freezing and pruning steps in VACUUM
	-->
	
	<listitem>
	<para>
	Allow vacuum to more efficiently remove and freeze tuples (John Naylor, Masahiko Sawada, Melanie Plageman)
	</para>
	</listitem>

> subtransactions (5bec1d6bc)

I looked at that item and I don't have a generic "make logical
replication apply faster" item to merge it into, and many
subtransactions seemed like enough of an edge-case that I didn't think
mentioning it make sense.  Can you see a good place to add it?

> - Add tests for XID wraparound (e255b646a)

I don't normally add testing infrastructure changes unless they are
major.

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 9 May 2024 10:17:03 -0400

> I think you mean a65724dfa.  The author should be 'Richard Guo'.

Wow the CTE item above it was done by Jian Guo.  I probably copied the
text from the line above it, modified the description, but thought the
author's name was the same, but it was not.  Fixed.

> I think maybe a similar revision can be applied to the item just above

Okay, I went with this text:

	<!--
	Author: Tom Lane <[email-masked]>
	2023-11-17 [f7816aec2] Extract column statistics from CTE references, if possib
	-->
	
	<listitem>
	<para>
	Allow the optimizer to improve CTE plans by considering the statistics of columns referenced in earlier row output clauses (Jian Guo, Tom Lane)
	</para>
	</listitem>
	
	<!--
	Author: Tom Lane <[email-masked]>
	2024-03-26 [a65724dfa] Propagate pathkeys from CTEs up to the outer query.
	-->
	
	<listitem>
	<para>
	Allow the optimizer to improve CTE plans by considering the sort order of columns referenced in earlier row output clauses (Richard Guo)
	</para>
	</listitem>

I did not use "leveraging" because I am concerned non-native English
speakers might find the term confusing.

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 9 May 2024 10:20:23 -0400

> Nikita Glukhov, Pavel Borisov, Yura Sokolov.

Wow, I try to only list source code items that have some user-facing
impact, and I don't think these do.  I do realize how important they are
though.  This gets into the balance of mentioning items _users_ need to
know about, vs. important improvements that _we_ know about.

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 9 May 2024 10:49:37 -0400

> https://www.postgresql.org/message-id/202404181849.6frtmajobe27%40alvherre.pgsql

I see it now, and I see Alvaro Herrera saying:

	> I wonder is there any incompatibility issue, or do we need to say something
	> about the new behavior when dropping a key column?
	
-->	Umm, yeah, maybe we should document it in ALTER TABLE DROP PRIMARY KEY
-->	and in the release notes to note the different behavior.

However, I don't see it mentioned as a release note item in the commit
message or mentioned in our docs. I suppose the release note text would
be:

	Removing a PRIMARY KEY will remove the NOT NULL column specification

	Previously the NOT NULL specification would be retained.

Do we have agreement that we want this release note item?

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 9 May 2024 10:50:45 -0400

> My name is listed twice in the "Improve psql tab completion" item.

You did such a great job I wanted to list you twice.  :-)  Actually, the
author list was so long I just didn't notice, fixed.

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 9 May 2024 10:51:38 -0400

> which Michael and I co-authored.

Yep, also my mistake, fixed.  My apologies.

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 9 May 2024 11:08:34 -0400

> < E.1.3.11. Additional Modules

Oh, it is in the pg_buffercache module --- I should have realized that
from the name, fixed.

> Then I found out official release notes don't have <section> attributes,

Uh, what are sections?  Did previous release notes have it?

>  from [1] is more descriptive.

Uh, I don't think people know what hash support functions are, but they
know what hash indexes are, and maybe hash joins and hash aggregates. 
Why do you consider the commit text better?

> i am not 100% sure of the meaning of "This is useful for extensions."

The commit says:

	commit 2b5154beab7
	Author: Tom Lane <[email-masked]>
	Date:   Fri Oct 20 12:28:38 2023 -0400
	
	    Extend ALTER OPERATOR to allow setting more optimization attributes.
	
	    Allow the COMMUTATOR, NEGATOR, MERGES, and HASHES attributes to be set
	    by ALTER OPERATOR.  However, we don't allow COMMUTATOR/NEGATOR to be
	    changed once set, nor allow the MERGES/HASHES flags to be unset once
	    set.  Changes like that might invalidate plans already made, and
	    dealing with the consequences seems like more trouble than it's worth.
-->	    The main use-case we foresee for this is to allow addition of missed
-->	    properties in extension update scripts, such as extending an existing
-->	    operator to support hashing.  So only transitions from not-set to set
	    states seem very useful.

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 9 May 2024 11:09:26 -0400

> This also enables hash join and hash aggregation on ltree columns.

Yes, please see my previous email where I am asking why being more
specific is worse.

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 9 May 2024 11:12:14 -0400

> (Egor Rogov, Soumyadeep Chakraborty)

Yes, good point, done.

> Display length and bounds histograms in pg_stats

Uh, isn't that assumed?  Is this a detail worth mentioning?

> Belyalov, Atsushi Torikoshi, Alex Shulgin, Jian He, Jian He, Yugo

Fixed.

---

From: Andrew Dunstan <[email-masked]>
Date: Thu, 9 May 2024 12:10:11 -0400

> I welcome feedback.  For some reason it was an easier job than usual.

  *

    Remove the ability to build Postgres with Visual Studio (Michael
    Paquier)

    Meson is now the only available Windows build method.

This is a category mistake. What was removed was the special code we had 
for building with VS, but not the ability to build with VS. You can 
build with VS using meson (see for example drongo on the buildfarm)

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 9 May 2024 12:29:38 -0400

On Thu, May  9, 2024 at 12:10:11PM -0400, Andrew Dunstan wrote:
>   • Remove the ability to build Postgres with Visual Studio (Michael Paquier)
> 
> This is a category mistake. What was removed was the special code we had for
> building with VS, but not the ability to build with VS. You can build with VS
> using meson (see for example drongo on the buildfarm)

Wow, okay, I am not surprised I was confused.  New text is:

	<!--
	Author: Michael Paquier <[email-masked]>
	2023-12-20 [1301c80b2] Remove MSVC scripts
	-->
	
	<listitem>
	<para>
	Remove the Microsoft Visual Studio Studio-specific Postgres build option (Michael Paquier)
	</para>
	
	<para>
	Meson is now the only method for Visual Studio builds.
	</para>
	</listitem>
	<!--
	Author: Michael Paquier <[email-masked]>
	2023-12-20 [1301c80b2] Remove MSVC scripts
	-->
	
	<listitem>
	<para>
	Remove the Microsoft Visual Studio Studio-specific Postgres build option (Michael Paquier)
	</para>
	
	<para>
	Meson is now the only method for Visual Studio builds.
	</para>
	</listitem>

---

From: Álvaro Herrera <[email-masked]>
Date: Thu, 9 May 2024 20:40:00 +0200

> Do we have agreement that we want this release note item?

Yes.  Maybe we want some others too (especially regarding inheritance,
but also regarding the way we handle the constraints internally), and
maybe in this one we want different wording.  How about something like
this:

  Removing a primary key constraint may change the nullability
  characteristic of the columns that the primary key covered.

  If explicit not-null constraints exist on the same column, then they
  continue to be /known not nullable/; otherwise they become /possibly
  nullable/.

This is largely based on the SQL standard's language of a column
descriptor having a "nullability characteristic", which for columns with
not-null or primary key constraints is "known not null".  I don't think
we use those terms anywhere.  I hope this isn't too confusing.

The standard's text on this, in section "4.13 Columns, fields, and
attributes", is

  Every column has a nullability characteristic that indicates whether
  the value from that column can be the null value. A nullability
  characteristic is either known not nullable or possibly nullable.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/

---

From: Thomas Munro <[email-masked]>
Date: Fri, 10 May 2024 08:05:43 +1200

> 2024-01-25 [820b5af73] jit: Require at least LLVM 10.

> Require LLVM version 10 or later (Peter Eisentraut)

Peter reviewed, I authored, and I think you intend to list authors in
parentheses.

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 9 May 2024 16:35:54 -0400

> Peter reviewed, I authored, and I think you intend to list authors in

Yes, my mistake, fixed.

---

From: Bharath Rupireddy <[email-masked]>
Date: Fri, 10 May 2024 13:54:30 +0530

> I welcome feedback.  For some reason it was an easier job than usual.

Thanks a lot for this work Bruce! It looks like commit
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=91f2cae7a4e664e9c0472b364c7db29d755ab151
is missing from daft release notes. Just curious to know if it's
intentional or a miss out.

-- 
Bharath Rupireddy

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 10 May 2024 09:50:01 -0400

> intentional or a miss out.

I did not mention it because the commit didn't mention any performance
benefit and it seemed more like an internal change than something people
needed to know about.  I could reword and merge it into this item, if
you think I should:

	 Improve performance of heavily-contended WAL writes (Bharath Rupireddy)

---

From: "Daniel Verite" <[email-masked]>
Date: Fri, 10 May 2024 18:29:11 +0200

Bruce Momjian wrote:

>  have committed the first draft of the PG 17 release notes;  you can
> see the results here:
> 

In the psql items, I'd suggest mentioning

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=90f5178

For the short description, maybe something like that:

- Improve FETCH_COUNT to work with all queries (Daniel Vérité)
Previously, results would be fetched in chunks only for queries
that start with the SELECT keyword.

Best regards,
-- 
Daniel Vérité
https://postgresql.verite.pro/
Twitter: @DanielVerite

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Fri, 10 May 2024 18:50:54 +0200

>         https://momjian.us/pgsql_docs/release-17.html

Great work!

There are two commits that I think would benefit from being listed
(but maybe they are already listed and I somehow missed them, or they
are left out on purpose for some reason):

- c4ab7da60617f020e8d75b1584d0754005d71830
- cafe1056558fe07cdc52b95205588fcd80870362

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 10 May 2024 15:47:04 -0400

> that start with the SELECT keyword.

Agreed, patch attached and applied.

  Only you can decide what is important to you.
diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index e4b34d827d1..08238be9cb7 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -1893,8 +1893,6 @@ This is similar to PQpipelineSync() but it does not flush to the server unless t
 <!--
 Author: Tom Lane <[email-masked]>
 2024-04-06 [4643a2b26] Support retrieval of results in chunks with libpq.
-Author: Tom Lane <[email-masked]>
-2024-04-06 [90f517821] Re-implement psql's FETCH_COUNT feature atop libpq's chu
 -->
 
 <listitem>
@@ -1937,6 +1935,17 @@ This is enabled with the client-side option sslnegotation=direct, requires ALPN,
 
      <itemizedlist>
 
+<!--
+Author: Tom Lane <[email-masked]>
+2024-04-06 [90f517821] Re-implement psql's FETCH_COUNT feature atop libpq's chu
+-->
+
+<listitem>
+<para>
+Allow FETCH_COUNT to work with non-SELECT queries (Daniel Vérité)
+</para>
+</listitem>
+
 <!--
 Author: Tom Lane <[email-masked]>
 2023-11-13 [d1379ebf4] Improve default and empty privilege outputs in psql.

---

From: Maiquel Grassi <[email-masked]>
Date: Fri, 10 May 2024 20:58:02 +0000

Mhd

Enviado desde Outlook para Android<https://aka.ms/AAb9ysg>
________________________________
From: Bruce Momjian <[email-masked]>
Sent: Friday, May 10, 2024 4:47:04 PM
To: Daniel Verite <[email-masked]>
Cc: PostgreSQL-development <[email-masked]>
Subject: Re: First draft of PG 17 release notes

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 10 May 2024 17:21:01 -0400

> are left out on purpose for some reason):

I looked at both of these.   In both cases I didn't see why the user
would need to know these changes were made:

---------------------------------------------------------------------------

> - c4ab7da60617f020e8d75b1584d0754005d71830

	commit c4ab7da6061
	Author: David Rowley <[email-masked]>
	Date:   Sun Apr 7 21:20:18 2024 +1200
	
	    Avoid needless large memcpys in libpq socket writing
	
	    Until now, when calling pq_putmessage to write new data to a libpq
	    socket, all writes are copied into a buffer and that buffer gets flushed
	    when full to avoid having to perform small writes to the socket.
	
	    There are cases where we must write large amounts of data to the socket,
	    sometimes larger than the size of the buffer.  In this case, it's
	    wasteful to memcpy this data into the buffer and flush it out, instead,
	    we can send it directly from the memory location that the data is already
	    stored in.
	
	    Here we adjust internal_putbytes() so that after having just flushed the
	    buffer to the socket, if the remaining bytes to send is as big or bigger
	    than the buffer size, we just send directly rather than needlessly
	    copying into the PqSendBuffer buffer first.
	
	    Examples of operations that write large amounts of data in one message
	    are; outputting large tuples with SELECT or COPY TO STDOUT and
	    pg_basebackup.
	
	    Author: Melih Mutlu
	    Reviewed-by: Heikki Linnakangas
	    Reviewed-by: Jelte Fennema-Nio
	    Reviewed-by: David Rowley
	    Reviewed-by: Ranier Vilela
	    Reviewed-by: Andres Freund
	    Discussion: https://postgr.es/m/[email-masked]

> - cafe1056558fe07cdc52b95205588fcd80870362

	commit cafe1056558
	Author: Robert Haas <[email-masked]>
	Date:   Tue Apr 2 10:26:10 2024 -0400
	
	    Allow SIGINT to cancel psql database reconnections.
	
	    After installing the SIGINT handler in psql, SIGINT can no longer cancel
	    database reconnections. For instance, if the user starts a reconnection
	    and then needs to do some form of interaction (ie psql is polling),
	    there is no way to cancel the reconnection process currently.
	
	    Use PQconnectStartParams() in order to insert a cancel_pressed check
	    into the polling loop.
	
	    Tristan Partin, reviewed by Gurjeet Singh, Heikki Linnakangas, Jelte
	    Fennema-Nio, and me.
	
	    Discussion: http://postgr.es/m/[email-masked]

---

From: Tom Lane <[email-masked]>
Date: Fri, 10 May 2024 17:31:33 -0400

> would need to know these changes were made:

I agree that the buffering change is not likely interesting, but
the fact that you can now control-C out of a psql "\c" command
is user-visible.  People might have internalized the fact that
it didn't work, or created complicated workarounds.

			regards, tom lane

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 10 May 2024 17:37:25 -0400

> it didn't work, or created complicated workarounds.

It was not clear to me what the user-visible behavior was with the
SIGINT control.  Yes, based on your details, it should be mentioned.

---

From: Andy Fan <[email-masked]>
Date: Sat, 11 May 2024 13:27:25 +0800

Hello Bruce,

> 	https://momjian.us/pgsql_docs/release-17.html

Thank you for working on this!

> I welcome feedback.  For some reason it was an easier job than usual.

Do you think we need to add the following 2 items?

- 9f133763961e280d8ba692bcad0b061b861e9138 this is an optimizer
  transform improvement.

- a8a968a8212ee3ef7f22795c834b33d871fac262 this is an optimizer costing
  improvement.

Both of them can generate a better plan on some cases. 

-- 
Best Regards
Andy Fan

---

From: David Rowley <[email-masked]>
Date: Sat, 11 May 2024 17:57:31 +1200

> - 9f133763961e280d8ba692bcad0b061b861e9138 this is an optimizer

I think this should be in the release notes.

Suggest:

* Allow correlated IN subqueries to be transformed into joins (Andy
Fan, Tom Lane)

> Both of them can generate a better plan on some cases.

I think this should be present too.

Suggest:

* Improve optimizer's ability to use cheap startup plans when querying
partitioned tables, inheritance parents and for UNION ALL (Andy Fan,
David Rowley)

Both under "E.1.3.1.1. Optimizer"

David

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Sat, 11 May 2024 15:57:49 +0200

> it didn't work, or created complicated workarounds.

The buffering change improved performance up to ~40% in some of the
benchmarks. The case it improves mostly is COPY of large rows and
streaming a base backup. That sounds user-visible enough to me to
warrant an entry imho.

---

From: Joe Conway <[email-masked]>
Date: Sat, 11 May 2024 10:24:39 -0400

> streaming a base backup. That sounds user-visible enough to me to

+1

-- 
Joe Conway

---

From: Andrew Dunstan <[email-masked]>
Date: Sat, 11 May 2024 15:32:55 -0400

> I welcome feedback.  For some reason it was an easier job than usual.

I don't like blowing my own horn but I feel commit 3311ea86ed "Introduce 
a non-recursive JSON parser" should be in the release notes. This isn't 
something that's purely internal, but it could be used by an extension 
or a client program to parse JSON documents that are too large to handle 
with the existing API.

Maybe "Introduce an incremental JSON parser" would have been a better 
headline.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

---

From: Bharath Rupireddy <[email-masked]>
Date: Mon, 13 May 2024 12:46:38 +0530

On Fri, May 10, 2024 at 7:20 PM Bruce Momjian <[email-masked]> wrote:
> needed to know about.

Yes, it's an internal feature for someone not using Direct IO for WAL
and helps achieve things mentioned at
https://www.postgresql.org/message-id/flat/20230125211540.zylu74dj2uuh3k7w%40awork3.anarazel.de#0cac0a0d219129e32329831adea05db5
(I'm hoping to target them for PG18). It starts to show visible
benefits if someone enables direct IO for WAL (for whatever reasons)
https://www.postgresql.org/message-id/CALj2ACV6rS%2B7iZx5%2BoAvyXJaN4AG-djAQeM1mrM%3DYSDkVrUs7g%40mail.gmail.com
and https://www.postgresql.org/message-id/20230127061745.46yu4ksitzociwkt%40awork3.anarazel.de.

I'm okay if 91f2cae7 is left out for the reason that Direct IO for WAL
isn't something used in production and debug_io_direct is a developer
option.

> I could reword and merge it into this item, if
> you think I should:
>

I think both the commits are for different purposes - one is for WAL
wrties, another is for WAL reads.

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 13 May 2024 20:30:59 -0400

> it didn't work, or created complicated workarounds.

Agreed, attached patch applied.

  Only you can decide what is important to you.
diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index 5a741ff16f1..9dd3954f3c2 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -1980,6 +1980,17 @@ The parameter is "min_rows".
 </para>
 </listitem>
 
+<!--
+Author: Robert Haas <[email-masked]>
+2024-04-02 [cafe10565] Allow SIGINT to cancel psql database reconnections.
+-->
+
+<listitem>
+<para>
+Allow psql connections to be canceled with control-C (Tristan Partin)
+</para>
+</listitem>
+
 <!--
 Author: Tom Lane <[email-masked]>
 2024-04-06 [90f517821] Re-implement psql's FETCH_COUNT feature atop libpq's chu

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 13 May 2024 20:56:26 -0400

> > streaming a base backup. That sounds user-visible enough to me to

Attached patch applied.

  Only you can decide what is important to you.
commit e87e7324555
Author: Bruce Momjian <[email-masked]>
Date:   Mon May 13 20:55:13 2024 -0400

    doc PG 17 relnotes:  add item about libpq large data transfers
    
    Reported-by: Jelte Fennema-Nio
    
    Discussion: https://postgr.es/m/[email-masked]
    
    Reviewed-by: Joe Conway
    
    Backpatch-through: master

diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index 9dd3954f3c2..38c14970822 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -1901,6 +1901,17 @@ Add libpq function PQsetChunkedRowsMode to allow retrieval of results in chunks
 </para>
 </listitem>
 
+<!--
+Author: David Rowley <[email-masked]>
+2024-04-07 [c4ab7da60] Avoid needless large memcpys in libpq socket writing
+-->
+
+<listitem>
+<para>
+Allow libpq to more efficiently transfer large blocks of data (Melih Mutlu)
+</para>
+</listitem>
+
 <!--
 Author: Heikki Linnakangas <[email-masked]>
 2024-04-08 [d39a49c1e] Support TLS handshake directly without SSLRequest negoti

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 13 May 2024 20:59:42 -0400

> - 9f133763961e280d8ba692bcad0b061b861e9138 this is an optimizer

It was unclear from the commit message exactly what user-visible
optimization this allowed.  Do you have details?

> - a8a968a8212ee3ef7f22795c834b33d871fac262 this is an optimizer costing

Does this allow faster UNION ALL with LIMIT, perhaps?

---

From: Tender Wang <[email-masked]>
Date: Tue, 14 May 2024 10:22:35 +0800

> https://www.postgresql.org/message-id/202404181849.6frtmajobe27%40alvherre.pgsql
Since Alvaro has reverted all changes to not-null constraints, so will not
have potential incompatibilities issue.
-- 
Tender Wang
OpenPie:  https://en.openpie.com/

---

From: Andy Fan <[email-masked]>
Date: Tue, 14 May 2024 10:32:14 +0800

> optimization this allowed.  Do you have details?

Yes, It allows the query like "SELECT * FROM t1 WHERE t1.a in (SELECT a
FROM t2 WHERE t2.b = t1.b)" be pulled up a semi join, hence more join
methods / join orders are possible.

> Does this allow faster UNION ALL with LIMIT, perhaps?

Yes, for example:  (subquery-1) UNION ALL (subquery-2) LIMIT n;

When planning the subquery-1 or subquery-2, limit N should be
considered. As a consequence, maybe hash join should be replaced with
Nested Loop. Before this commits, it is ignored if it is flatten into 
appendrel, and the "flatten" happens very often.

David provided a summary for the both commits in [1].

[1]
https://www.postgresql.org/message-id/CAApHDvqAQgq27LgYmJ85VVGTR0%3DhRW6HHq2oZgK0ZiYC_a%2BEww%40mail.gmail.com 

-- 
Best Regards
Andy Fan

---

From: Elena Indrupskaya <[email-masked]>
Date: Tue, 14 May 2024 13:34:56 +0300

Hi everybody,

Being a technical writer, I attached a small patch that fixes minor 
language stuff.

Thank you.

Elena Indrupskaya

Postgres Professional Company

Moscow, Russia

diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index 5a741ff16f..1ecf40fc73 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -73,7 +73,7 @@ Author: Michael Paquier <[email-masked]>
 
 <listitem>
 <para>
-Restrict "ago" to only appear at the end of in interval values (Joseph Koshakow)
+Restrict "ago" to only appear at the end in interval values (Joseph Koshakow)
 </para>
 
 <para>
@@ -456,7 +456,7 @@ Author: Tomas Vondra <[email-masked]>
 
 <listitem>
 <para>
-Allow a BRIN indexes to be created using parallel workers (Tomas Vondra, Matthias van de Meent)
+Allow BRIN indexes to be created using parallel workers (Tomas Vondra, Matthias van de Meent)
 </para>
 </listitem>
 
@@ -941,7 +941,7 @@ Allow the creation of WAL summarization files (Robert Haas, Nathan Bossart, Hube
 </para>
 
 <para>
-These files record the block numbers that have changed within an LSN range, and is useful for incremental file system backups.  This is controlled by the server variables
+These files record the block numbers that have changed within an LSN range and are useful for incremental file system backups.  This is controlled by the server variables
 summarize_wal and wal_summarize_keep_time, and introspected with pg_available_wal_summaries(), pg_wal_summary_contents(), and pg_get_wal_summarizer_state().
 </para>
 </listitem>
@@ -1113,7 +1113,7 @@ Allow the application of logical replication changes to use hash indexes on the
 </para>
 
 <para>
-Previously only btree indexes could be use for this purpose.
+Previously only btree indexes could be used for this purpose.
 </para>
 </listitem>
 
@@ -2185,7 +2185,7 @@ Allow pg_basebackup and pg_receivewal to use dbname in their connection specific
 </para>
 
 <para>
-This is useful for connection poolers who are sensitive to the database name.
+This is useful for connection poolers that are sensitive to the database name.
 </para>
 </listitem>
 
@@ -2346,7 +2346,7 @@ Author: Michael Paquier <[email-masked]>
 
 <listitem>
 <para>
-Remove the Microsoft Visual Studio Studio-specific Postgres build option (Michael Paquier)
+Remove the Microsoft Visual Studio-specific Postgres build option (Michael Paquier)
 </para>
 
 <para>

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Tue, 14 May 2024 14:20:24 +0200

> > > streaming a base backup. That sounds user-visible enough to me to

I think we shouldn't list this under the libpq changes and shouldn't
mention libpq in the description, since this patch changes
src/backend/libpq files instead of src/interfaces/libpq files. I think
it should be in the "General performance" section and describe the
change as something like the below:

Improve performance when transferring large blocks of data to a client

PS. I completely understand that this was not clear from the commit message.

---

From: Pantelis Theodosiou <[email-masked]>
Date: Tue, 14 May 2024 14:58:41 +0100

On Thu, May 9, 2024 at 5:03 AM Bruce Momjian <[email-masked]> wrote

This looks better if "more case" -> "more cases" :
>  Allow query nodes to be run in parallel in more case (Tom Lane)

---

From: Melanie Plageman <[email-masked]>
Date: Tue, 14 May 2024 15:39:26 -0400

>         https://momjian.us/pgsql_docs/release-17.html

I had two comments:

--------
I think the read stream item:

"Allow the grouping of file system reads with the new system variable
io_combine_limit"

Might be better if it mentions the effect, like:

"Reduce system calls by automatically merging reads up to io_combine_limit"
-------
For the vacuum feature:

"Allow vacuum to more efficiently remove and freeze tuples"

I think that we need to more clearly point out the implications of the
feature added by Sawada-san (and reviewed by John) in 667e65aac35497.
Vacuum no longer uses a fixed amount of memory for dead tuple TID
storage and it is not preallocated. This affects users as they may
want to change their configuration (and expectations).

If you make that item more specific to their work, you should also
remove my name, as the work I did on vacuum this release was unrelated
to their work on dead tuple TID storage.

The work Heikki and I did which culminated in 6dbb490261 mainly has
the impact of improving vacuum's performance (vacuum emits less WAL
and is more efficient). So you could argue for removing it from the
release notes if you are using the requirement that performance
improvements don't go in the release notes.

However, one of the preliminary commits for this f83d70976 does change
WAL format. There are three WAL records which no longer exist as
separate records. Do users care about this?

- Melanie

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 14 May 2024 20:37:19 -0400

> David provided a summary for the both commits in [1].

Okay, attached patch applied.

  Only you can decide what is important to you.
diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index 38c14970822..fa0a703629c 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -356,6 +356,28 @@ Improve optimization of range values when using containment operators &lt;@ and
 </para>
 </listitem>
 
+<!--
+Author: Alexander Korotkov <[email-masked]>
+2024-02-15 [9f1337639] Pull up ANY-SUBLINK with the necessary lateral support.
+-->
+
+<listitem>
+<para>
+Allow correlated IN subqueries to be transformed into joins (Andy Fan, Tom Lane)
+</para>
+</listitem>
+
+<!--
+Author: David Rowley <[email-masked]>
+2023-10-05 [a8a968a82] Consider cheap startup paths in add_paths_to_append_rel
+-->
+
+<listitem>
+<para>
+Improve optimization of the LIMIT clause on partitioned tables, inheritance parents, and UNION ALL queries (Andy Fan, David Rowley)
+</para>
+</listitem>
+
 <!--
 Author: Tom Lane <[email-masked]>
 2023-07-14 [e08d74ca1] Allow plan nodes with initPlans to be considered paralle

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 14 May 2024 20:39:29 -0400

On Sat, May 11, 2024 at 03:32:55PM -0400, Andrew Dunstan wrote:
> I don't like blowing my own horn but I feel commit 3311ea86ed "Introduce a
> non-recursive JSON parser" should be in the release notes. This isn't
> something that's purely internal, but it could be used by an extension or a
> client program to parse JSON documents that are too large to handle with the
> existing API.
> 

Well, this gets into a level of detail that is beyond the average
reader.  I think at that level people will need to read the git logs or
review the code.  Do we use it for anything yet?

It could be put in the source code section but I try to only have
user-visible stuff there.

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 14 May 2024 20:43:33 -0400

On Tue, May 14, 2024 at 01:34:56PM +0300, Elena Indrupskaya wrote:
> Being a technical writer, I attached a small patch that fixes minor language
> stuff.

You are absolutely correct.  Patch applied, thanks.

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 14 May 2024 20:47:10 -0400

> PS. I completely understand that this was not clear from the commit message.

Okay, I went with your wording.  Attached patch applied.

  Only you can decide what is important to you.
diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index a3b4a8fb3b9..448f5653bc5 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -563,6 +563,17 @@ Improve performance of heavily-contended WAL writes (Bharath Rupireddy)
 </para>
 </listitem>
 
+<!--
+Author: David Rowley <[email-masked]>
+2024-04-07 [c4ab7da60] Avoid needless large memcpys in libpq socket writing
+-->
+
+<listitem>
+<para>
+Improve performance when transferring large blocks of data to a client (Melih Mutlu)
+</para>
+</listitem>
+
 <!--
 Author: Thomas Munro <[email-masked]>
 2024-04-03 [210622c60] Provide vectored variant of ReadBuffer().
@@ -1923,17 +1934,6 @@ Add libpq function PQsetChunkedRowsMode to allow retrieval of results in chunks
 </para>
 </listitem>
 
-<!--
-Author: David Rowley <[email-masked]>
-2024-04-07 [c4ab7da60] Avoid needless large memcpys in libpq socket writing
--->
-
-<listitem>
-<para>
-Allow libpq to more efficiently transfer large blocks of data (Melih Mutlu)
-</para>
-</listitem>
-
 <!--
 Author: Heikki Linnakangas <[email-masked]>
 2024-04-08 [d39a49c1e] Support TLS handshake directly without SSLRequest negoti

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 14 May 2024 20:48:21 -0400

> >  Allow query nodes to be run in parallel in more case (Tom Lane)

Yes, you are correct, fixed.

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 14 May 2024 21:00:50 -0400

> "Reduce system calls by automatically merging reads up to io_combine_limit"

Uh, as I understand it, the reduced number of system calls is not the
value of the feature, but rather the ability to request a larger block
from the I/O subsystem.  Without it, you have to make a request and wait
for each request to finish.  I am open to new wording, but I am not sure
your new wording is accurate.

> separate records. Do users care about this?

I don't think users really care about these details, just that it is
faster so they will not be surprised if there is a change.  I was
purposely vague to group multiple commits into the single item.  By
grouping them together, I got enough impact to warrant listing it.  If
you split it apart, it is harder to justify mentioning them.

---

From: Masahiko Sawada <[email-masked]>
Date: Wed, 15 May 2024 10:10:28 +0900

> mentioning it make sense.  Can you see a good place to add it?

I think that since many subtransactions cases are no longer becoming
edge-cases these days, we needed to improve that and it might be
helpful for users to mention it. How about the following item for
example?

Improve logical decoding performance in cases where there are many
subtransactions.

> I don't normally add testing infrastructure changes unless they are

I've seen we had such item, for example in PG14 release note:

Add a test module for the regular expression package (Tom Lane)

But if our policy has already changed, I'm okay with not mentioning
the xid_wraparound test in the PG17 release note.

Regards,

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 14 May 2024 22:02:11 -0400

On Tue, May 14, 2024 at 10:22:35AM +0800, Tender Wang wrote:
>     https://www.postgresql.org/message-id/
>     202404181849.6frtmajobe27%40alvherre.pgsql
> 
> 
> 
> Since Alvaro has reverted all changes to not-null constraints, so will not have
> potential incompatibilities issue.

Agreed.

---

From: David Rowley <[email-masked]>
Date: Wed, 15 May 2024 14:03:32 +1200

> your new wording is accurate.

I think you have the cause and effect backwards. There's no advantage
to reading 128KB if you only need 8KB.  It's the fact that doing
*larger* reads allows *fewer* reads that allows it to be more
efficient.  There are also the efficiency gains from fadvise
POSIX_FADV_WILLNEED. I'm unsure how to jam that into a short sentence.
Maybe; "Optimize reading of tables by allowing pages to be prefetched
and read in chunks up to io_combine_limit", or a bit more buzzy;
"Optimize reading of tables by allowing pages to be prefetched and
performing vectored reads in chunks up to io_combine_limit".

David

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 14 May 2024 22:06:17 -0400

> performing vectored reads in chunks up to io_combine_limit".

Yes, my point is that it is not the number of system calls or system
call overhead that is the advantage of this patch, but the ability to
request more of the I/O system in one call, which is not the same as
system calls.

I can use your wording, but how much prefetching to we enable now?

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 14 May 2024 22:20:11 -0400

> Improve logical decoding performance in cases where there are many

Okay, item added in the attached applied patch.

> the xid_wraparound test in the PG17 release note.

Uh, that PG 14 test suite was huge and flushed out a lot of bugs, not
only in our regex code but I think in the TCL/Henry Spencer regex
library we inherited.

We add 10-40 tests every year, and how many do I mention in the release
notes?  You had to go back to PG 14 to find one.  We have not changed
our release note "test item" criteria --- I only mention tests that are
significant to our userbase.  I think that test suite was significant to
anyone using the TCL/Henry Spencer regex library.

If you want your test mentioned, you have to explain why it is useful
for users to know about it, or the value it brings them.

  Only you can decide what is important to you.
diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index 510810b53dc..e68c499e0db 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -1150,6 +1150,17 @@ Previously only btree indexes could be used for this purpose.
 </para>
 </listitem>
 
+<!--
+Author: Masahiko Sawada <[email-masked]>
+2024-04-03 [5bec1d6bc] Improve eviction algorithm in ReorderBuffer using max-he
+-->
+
+<listitem>
+<para>
+Improve logical decoding performance in cases where there are many subtransactions (Masahiko Sawada)
+</para>
+</listitem>
+
 <!--
 Author: Amit Kapila <[email-masked]>
 2023-10-17 [79243de13] Restart the apply worker if the privileges have been rev

---

From: David Rowley <[email-masked]>
Date: Wed, 15 May 2024 14:24:15 +1200

> I can use your wording, but how much prefetching to we enable now?

I believe the read stream API is used for Seq Scan, ANALYZE and
pg_prewarm().  fadvise() is used when the next buffer that's required
is not in shared buffers on any build that has defined
HAVE_DECL_POSIX_FADVISE.

David

---

From: Alvaro Herrera <[email-masked]>
Date: Wed, 15 May 2024 10:38:20 +0200

> you split it apart, it is harder to justify mentioning them.

I disagree with this.  IMO the impact of the Sawada/Naylor change is
likely to be enormous for people with large tables and large numbers of
tuples to clean up (I know we've had a number of customers in this
situation, I can't imagine any Postgres service provider that doesn't).
The fact that maintenance_work_mem is no longer capped at 1GB is very
important and I think we should mention that explicitly in the release
notes, as setting it higher could make a big difference in vacuum run
times.

I don't know what's the impact of the Plageman/Linnakangas work, but
since there are no user-visible consequences other than it being faster,
I agree it could be put more succintly, perhaps together as a sub-para
of the same item.

What about something like this?

<para>
 Lift the 1 GB allocation limit for vacuum memory usage for dead
 tuples, and make storage more compact and performant.
</para>
<para>
 This can reduce the number of index passes that vacuum has to perform
 for tables with many dead tuples, shortening vacuum times.
</para>
<para>
 Also, the WAL traffic caused by vacuum has been made more compact.
</para>

> > However, one of the preliminary commits for this f83d70976 does
> > change WAL format. There are three WAL records which no longer exist
> > as separate records. Do users care about this?

I don't think so.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"You don't solve a bad join with SELECT DISTINCT" #CupsOfFail
https://twitter.com/connor_mc_d/status/1431240081726115845

---

From: Amit Kapila <[email-masked]>
Date: Wed, 15 May 2024 18:43:51 +0530

> I can use your wording, but how much prefetching to we enable now?

Shouldn't we need to include commit
b5a9b18cd0bc6f0124664999b31a00a264d16913 with this item?

-- 
With Regards,
Amit Kapila.

---

From: jian he <[email-masked]>
Date: Thu, 16 May 2024 10:39:18 +0800

>> Add local I/O block read/write timing statistics columns of pg_stat_statement (Nazir Bilal Yavuz)
>> The new columns are "local_blk_read_time" and "local_blk_write_time".
here, "pg_stat_statement" should be "pg_stat_statements"?

>> Add optional fourth parameter to pg_stat_statements_reset() to allow for the resetting of only min/max statistics (Andrei Zubkov)
>> This parameter defaults to "false".
here, "parameter",  should be "argument"?

maybe
>> Add optional fourth boolean argument (minmax_only) to pg_stat_statements_reset() to allow for the resetting of only min/max statistics (Andrei Zubkov)
>> This argument defaults to "false".
----------------------------------------------------------------
in section: E.1.2. Migration to Version 17

>> Rename I/O block read/write timing statistics columns of pg_stat_statement (Nazir Bilal Yavuz)
>> This renames "blk_read_time" to "shared_blk_read_time", and "blk_write_time" to "shared_blk_write_time".

"pg_stat_statement" should be "pg_stat_statements"?

also, we only mentioned, pg_stat_statements some columns name changed
in "E.1.2. Migration to Version 17"
but if you look at the release note pg_stat_statements section,
we added a bunch of columns, which are far more incompatibile than
just colunm name changes.

not sure we need add these in section "E.1.2. Migration to Version 17"

---

From: "David G. Johnston" <[email-masked]>
Date: Wed, 15 May 2024 19:53:48 -0700

On Wednesday, May 15, 2024, jian he <[email-masked]> wrote:

> >> This renames "blk_read_time" to "shared_blk_read_time", and
> "blk_write_time" to "shared_blk_write_time".
>
> we only mentioned, pg_stat_statements some columns name changed
New columns are not a migration issue since nothing being migrated forward
ever referenced them.  Its the ones that existing code knows about that
we’ve removed (including renames) that matter from a migration perspective.

David J.

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 15 May 2024 22:55:47 -0400

Agreed.

> >> This argument defaults to "false".

Sure.

Yes, fixed.

> not sure we need add these in section "E.1.2. Migration to Version 17"

Well, new columns don't cause breakage like renamed columns, which is
why I only put renames/removed columns in the migration section.

Also, thanks everyone for the release notes feedback.  In some cases I
made a mistake, and in some cases I misjudged the item.

---

From: Andres Freund <[email-masked]>
Date: Wed, 15 May 2024 20:48:02 -0700

Hi,

> notes, as setting it higher could make a big difference in vacuum run

+many.

We're having this debate every release. I think the ongoing reticence to note
performance improvements in the release notes is hurting Postgres.

For one, performance improvements are one of the prime reason users
upgrade. Without them being noted anywhere more dense than the commit log,
it's very hard to figure out what improved for users. A halfway widely
applicable performance improvement is far more impactful than many of the
feature changes we do list in the release notes.

For another, it's also very frustrating for developers that focus on
performance. The reticence to note their work, while noting other, far
smaller, things in the release notes, pretty much tells us that our work isn't
valued.

Greetings,

Andres Freund

---

From: jian he <[email-masked]>
Date: Thu, 16 May 2024 16:29:38 +0800

>> Add jsonpath methods to convert JSON values to different data types (Jeevan Chalke)
>> The jsonpath methods are .bigint(), .boolean(), .date(), .decimal([precision [, scale]]), .integer(), .number(), .string(), .time(), .time_tz(), .timestamp(), and .timestamp_tz().

I think it's slightly incorrect.

for example:
select jsonb_path_query('"2023-08-15"', '$.date()');
I think it does is trying to validate json value "2023-08-15" can be a
date value, if so, print json string out, else error out.

"convert JSON values to different data types"
meaning that we are converting json values to another data type, date?

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Thu, 16 May 2024 11:49:24 +0200

> smaller, things in the release notes, pretty much tells us that our work isn't

+1 to the general gist of listing every perf improvement **and memory
usage reduction** in the release notes. Most of them are already
grouped together in a dedicated "General performance" section anyway,
having that section be big would only be good imho to show that we're
committed to improving perf.

I think one thing would make this a lot easier though is if commits
that knowlingy impact perf would clearly say so in the commit message,
because now it's sometimes hard to spot as someone not deeply involved
with the specific patch. e.g. c4ab7da606 doesn't mention performance
at all, so I'm not surprised it wasn't listed initially. And while
667e65aac3 states that multiple rounds of heap scanning is now
extremely rare, it doesn't explicitly state what the kind of perf
impact can be expected because of that.

Maybe something like introducing a common "Perf-Improvement: true"
marker in the commit message and when doing so add a clear paragraph
explaining the expected perf impact perf impact. Another option could
be to add a "User Impact" section to the commit message, where an
author could add their suggestion for a release note entry. So
basically this suggestion boils down to more clearly mentioning user
impact in commit messages, instead of mostly/only including
technical/implementation details.

---

From: Joe Conway <[email-masked]>
Date: Thu, 16 May 2024 08:09:56 -0400

> feature changes we do list in the release notes.

many++

> smaller, things in the release notes, pretty much tells us that our work isn't

agreed

---

From: Melanie Plageman <[email-masked]>
Date: Thu, 16 May 2024 09:09:11 -0400

> feature changes we do list in the release notes.

The practical reason this matters to users is that they want to change
their configuration or expectations in response to performance
improvements.

And also, as Jelte mentions upthread, describing performance
improvements made each release in Postgres makes it clear that we are
consistently improving it.

> smaller, things in the release notes, pretty much tells us that our work isn't

+many

- Melanie

---

From: Peter Geoghegan <[email-masked]>
Date: Thu, 16 May 2024 10:55:25 -0400

> > notes, as setting it higher could make a big difference in vacuum run

TIDStore/the lifting of the maintenance_work_mem cap is likely to make
the performance of VACUUM a lot more predictable, overall. While most
VACUUM operations don't hit the limit, the limit is disproportionately
involved in cases where (for whatever reason) vacuuming becomes a long
and painful process. Even if you as a user never run into such a
problem, you still spend time worrying about it, and/or taking
measures to make sure it doesn't affect you.

The justification for not including mention of these items is that
they're not very relevant to users. I find that hard to square with
what does get included. For example, the "Source Code" section is full
of highly niche items. Items that are low impact, even for users
that'll benefit the most. Also, "Monitoring" often mentions monitoring
improvements that expose low-level implementation details (e.g. SLRU
statistics), even though there's a good chance that Bruce wouldn't
include an item for some improvement to the SLRU subsystem itself.

If somebody puts in an enormous amount of effort to get a big
performance improvement over the line, then ISTM that that effort is a
useful signal when the time comes to write the release notes (at least
up to a point). For example, Masahiko and John spent about 2 years on
the TIDStore thing, on and off. These things do not happen in a vacuum
(no pun intended). Common sense tells me that they went to those
lengths precisely because they understood that it very much was
relevant to users. That belief would have been reinforced by both
experience, and by discussion on the list during the development of
the feature.

To be fair to Bruce, it probably really is true that most individual
users won't care about (say) TIDStore. But it's probably also true
that most individual users don't care about the release notes, or at
most skim the major items.

-- 
Peter Geoghegan

---

From: Andrew Dunstan <[email-masked]>
Date: Thu, 16 May 2024 11:50:20 -0400

> review the code.  Do we use it for anything yet?

Yes, certainly, it's used in handling backup manifests. Without it we 
can't handle huge manifests. See commits ea7b4e9a2a and 222e11a10a.

Other uses are in the works.

cheers

andrew

---

From: jian he <[email-masked]>
Date: Fri, 17 May 2024 21:22:59 +0800

> which is similar to recent releases:

This thread mentioned performance.
actually this[1] refactored some interval aggregation related functions,
which will make these two aggregate function: avg(interval), sum(interval)
run faster, especially avg(interval).
see [2].
well, I guess, this is a kind of niche performance improvement to be
mentioned separately.

these 3 items need to be removed, because of
https://git.postgresql.org/cgit/postgresql.git/commit/?id=8aee330af55d8a759b2b73f5a771d9d34a7b887f

>> Add stratnum GiST support function (Paul A. Jungwirth)

>> Allow foreign keys to reference WITHOUT OVERLAPS primary keys (Paul A. Jungwirth)
>> The keyword PERIOD is used for this purpose.

>> Allow PRIMARY KEY and UNIQUE constraints to use WITHOUT OVERLAPS for non-overlapping exclusion constraints (Paul A. Jungwirth)

[1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=519fc1bd9e9d7b408903e44f55f83f6db30742b7
[2] https://www.postgresql.org/message-id/CAEZATCUJ0xjyQUL7SHKxJ5a%2BDm5pjoq-WO3NtkDLi6c76rh58w%40mail.gmail.com

---

From: "Daniel Verite" <[email-masked]>
Date: Fri, 17 May 2024 15:42:44 +0200

> 	https://momjian.us/pgsql_docs/release-17.html

About the changes in collations:

<quote>
  Create a "builtin" collation provider similar to libc's C locale
  (Jeff Davis)

  It uses a "C" locale which is identical but independent of
  libc, but it allows the use of non-"C" collations like "en_US"
  and "C.UTF-8" with the "C" locale, which libc does not. MORE?
</quote>

The new builtin provider has two collations:
* ucs_basic which is 100% identical to "C". It was introduced
several versions ago and the v17 novelty is simply to change
its pg_collation.collprovider from 'c' to 'b'.

* pg_c_utf8 which sorts like "C" but is Unicode-aware for
the rest, which makes it quite different from "C".
It's also different from the other UTF-8 collations that could
be used up to v17 in that it does not depend on an external
library, making it free from the collation OS-upgrade risks.

The part that is concretely of interest to users is the introduction
of pg_c_utf8. As described in [1]:

<quote>
pg_c_utf8

 This collation sorts by Unicode code point values rather than
 natural language order. For the functions lower, initcap, and
 upper, it uses Unicode simple case mapping. For pattern
 matching (including regular expressions), it uses the POSIX
 Compatible variant of Unicode Compatibility Properties. Behavior
 is efficient and stable within a Postgres major version. This
 collation is only available for encoding UTF8.
</quote>

I'd suggest that the relnote entry should be more like a condensed
version of that description, without mentioning en_US or C.UTF-8,
whose existence and semantics are OS-dependent, contrary to pg_c_utf8.

[1] https://www.postgresql.org/docs/devel/collation.html

Best regards,

---

From: Jeff Davis <[email-masked]>
Date: Fri, 17 May 2024 13:30:03 -0700

For this item:

    Create a "builtin" collation provider similar to libc's C
    locale (Jeff Davis)

I suggest something more like:

    New, platform-independent "builtin" collation
    provider. (Jeff Davis)

    Currently, it offers the "C" and "C.UTF-8" locales. The
    "C.UTF-8" locale combines stable and fast code point order
    collation with Unicode character semantics.

Regards,
	Jeff Davis

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 18 May 2024 10:59:47 -0400

> feature changes we do list in the release notes.

I agree the impact of performance improvements are often greater than
the average release note item.  However, if people expect Postgres to be
faster, is it important for them to know _why_ it is faster?

If we add a new flag to a command, people will want to know about it so
they can make use of it, or if there is a performance improvement that
allows new workloads, they will want to know about that too so they can
consider those workloads.

On the flip side, a performance improvement that makes everything 10%
faster has little behavioral change for users, and in fact I think we
get ~6% faster in every major release.

> smaller, things in the release notes, pretty much tells us that our work isn't

Yes, but are we willing to add text that every user will have to read
just for this purpose?

One think we _could_ do is to create a generic performance release note
item saying performance has been improved in the following areas, with
no more details, but we can list the authors on the item.

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 18 May 2024 11:13:54 -0400

> > smaller, things in the release notes, pretty much tells us that our work isn't

Please see the email I just posted.  There are three goals we have to
adjust for:

1.  short release notes so they are readable
2.  giving people credit for performance improvements
3.  showing people Postgres cares about performance

I would like to achieve 2 & 3 without harming #1.  My experience is if I
am reading a long document, and I get to a section where I start to
wonder, "Why should I care about this?", I start to skim the rest of
the document.  I am particularly critical if I start to wonder, "Why
does the author _think_ I should care about this?" becasue it feels like
the author is writing for him/herself and not the audience.

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 18 May 2024 12:11:38 -0400

> meaning that we are converting json values to another data type, date?

I see your point.  I have reworded it to be:

	Add jsonpath methods to convert JSON values to other JSON data
	types (Jeevan Chalke)

Does that help?  I think your example is causing confusion because once
JSON values enter the SQL data type space, they are strings.

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 18 May 2024 12:50:53 -0400

On Thu, May 16, 2024 at 11:50:20AM -0400, Andrew Dunstan wrote:
> Yes, certainly, it's used in handling backup manifests. Without it we can't
> handle huge manifests. See commits ea7b4e9a2a and 222e11a10a.
> 

Okay, added in the attached applied patch.

  Only you can decide what is important to you.
diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index 428cb5c5a2e..9c511848943 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -2451,6 +2451,17 @@ User-defined data type receive functions will no longer receive their data null-
 </para>
 </listitem>
 
+<!--
+Author: Andrew Dunstan <[email-masked]>
+2024-04-04 [3311ea86e] Introduce a non-recursive JSON parser
+-->
+
+<listitem>
+<para>
+Add incremental JSON parser for use with huge JSON documents (Andrew Dunstan)
+</para>
+</listitem>
+
 <!--
 Author: Nathan Bossart <[email-masked]>
 2024-02-28 [363eb0599] Convert README to Markdown.

---

From: Andrew Dunstan <[email-masked]>
Date: Sat, 18 May 2024 16:37:54 -0400

Thanks

cheers

andrew

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 18 May 2024 17:37:29 -0400

> [2] https://www.postgresql.org/message-id/CAEZATCUJ0xjyQUL7SHKxJ5a%2BDm5pjoq-WO3NtkDLi6c76rh58w%40mail.gmail.com

Agreed, I have applied the attached patch to make the release notes
current.

index 9c511848943..0bc1c9a14ad 100644
@@ -6,7 +6,7 @@
 
   <formalpara>
    <title>Release date:</title>
-   <para>2024-??-??, AS OF 2024-05-14</para>
+   <para>2024-??-??, AS OF 2024-05-18</para>
   </formalpara>
 
   <sect2 id="release-17-highlights">
@@ -480,17 +480,6 @@ Author: Tomas Vondra <[email-masked]>
 <para>
 Allow BRIN indexes to be created using parallel workers (Tomas Vondra, Matthias van de Meent)
 </para>
-</listitem>
-
-<!--
-Author: Peter Eisentraut <[email-masked]>
-2024-01-19 [6db4598fc] Add stratnum GiST support function
--->
-
-<listitem>
-<para>
-Add stratnum GiST support function (Paul A. Jungwirth)
-</para>
 </listitem>
 
      </itemizedlist>
@@ -1467,34 +1456,6 @@ Add DEFAULT setting for ALTER TABLE .. SET ACCESS METHOD (Michael Paquier)
 </para>
 </listitem>
 
-<!--
-Author: Peter Eisentraut <[email-masked]>
-2024-03-24 [34768ee36] Add temporal FOREIGN KEY contraints
--->
-
-<listitem>
-<para>
-Allow foreign keys to reference WITHOUT OVERLAPS primary keys (Paul A. Jungwirth)
-</para>
-
-<para>
-The keyword PERIOD is used for this purpose.
-</para>
-</listitem>
-
-<!--
-Author: Peter Eisentraut <[email-masked]>
-2024-01-24 [46a0cd4ce] Add temporal PRIMARY KEY and UNIQUE constraints
-Author: Peter Eisentraut <[email-masked]>
-2024-03-05 [030e10ff1] Rename pg_constraint.conwithoutoverlaps to conperiod
--->
-
-<listitem>
-<para>
-Allow PRIMARY KEY and UNIQUE constraints to use WITHOUT OVERLAPS for non-overlapping exclusion constraints (Paul A. Jungwirth)
-</para>
-</listitem>
-
 <!--
 Author: Alexander Korotkov <[email-masked]>
 2023-10-16 [e83d1b0c4] Add support event triggers on authenticated login
@@ -1957,6 +1918,8 @@ Author: Heikki Linnakangas <[email-masked]>
 2024-04-29 [17a834a04] Reject SSL connection if ALPN is used but there's no com
 Author: Heikki Linnakangas <[email-masked]>
 2024-05-11 [407e0b023] Change ALPN protocol ID to IANA-approved "postgresql"
+Author: Heikki Linnakangas <[email-masked]>
+2024-05-16 [fb5718f35] Remove option to fall back from direct to postgres SSL n
 -->
 
 <listitem>

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 18 May 2024 17:51:56 -0400

>     collation with Unicode character semantics.

Okay, I went with the attached applied patch.  Adjustments?

  Only you can decide what is important to you.
diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index 0bc1c9a14ad..5d2fcd7d7de 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -886,11 +886,11 @@ Author: Jeff Davis <[email-masked]>
 
 <listitem>
 <para>
-Create a "builtin" collation provider similar to libc's C locale (Jeff Davis)
+Create "builtin" collation provider similar to libc's C locale (Jeff Davis)
 </para>
 
 <para>
-It uses a "C" locale which is identical but independent of libc, but it allows the use of non-"C" collations like "en_US" and "C.UTF-8" with the "C" locale, which libc does not.  MORE?
+While its C locale is similar but independent of libc, its C.UTF-8 locale sorts by Unicode code points and has Unicode-based case folding.
 </para>
 </listitem>

---

From: Jeff Davis <[email-masked]>
Date: Mon, 20 May 2024 11:48:09 -0700

> Okay, I went with the attached applied patch.  Adjustments?

I think it should have more emphasis on the actual new feature: a
platform-independent builtin collation provider and the C.UTF-8 locale.

The user can look at the documentation for comparison with libc.

Regards,
	Jeff Davis

---

From: Amit Langote <[email-masked]>
Date: Tue, 21 May 2024 11:20:02 +0900

> I welcome feedback.  For some reason it was an easier job than usual.

Thanks Bruce for working on this as always.

Failed to notice when I read the notes before:

<listitem>
<para>
Add SQL/JSON constructor functions JSON(), JSON_SCALAR(), and
JSON_SERIALIZE() (Amit Langote)
</para>
</listitem>

Should be:

<listitem>
<para>
Add SQL/JSON constructor functions JSON(), JSON_SCALAR(), and
JSON_SERIALIZE() (Nikita Glukhov, Teodor Sigaev, Oleg Bartunov,
Alexander Korotkov, Andrew Dunstan, Amit Langote)
</para>
</listitem>

Patch attached.

-- 
Thanks, Amit Langote

---

From: Andres Freund <[email-masked]>
Date: Tue, 21 May 2024 09:40:28 -0700

Hi,

On 2024-05-18 11:13:54 -0400, Bruce Momjian wrote:
> the document.

I agree keeping things reasonably short is important. But I don't think you're
evenly applying it as a goal.

Just skimming the notes from the end, I see
- an 8 entries long pg_stat_statements section
- multiple entries about "Create custom wait events for ..."
- three entries about adding --all to {reindexdb,vacuumdb,clusterdb}.
- an entry about adding long options to pg_archivecleanup
- two entries about grantable maintenance rights, once via pg_maintain, once
  per-table
- separate entries about pg_stat_reset_slru(), pg_stat_reset_shared("slru"),

If you're concerned about brevity, we can make things shorter without skipping
over most performance imporvements.

> I am particularly critical if I start to wonder, "Why

FWIW, I think it's a good thing for somebody other than the author to have a
hand in writing a release notes entry for a change. The primary author(s) are
often too deep into some issue to have a good view of the right level of
detail and understandability.

Greetings,

Andres Freund

---

From: Masahiko Sawada <[email-masked]>
Date: Wed, 22 May 2024 11:29:06 +0900

Hi,

> which is similar to recent releases:

I found a typo:

s/pg_statstatement/pg_stat_statement/

I've attached a patch to fix it.

Regards,

---

From: torikoshia <[email-masked]>
Date: Wed, 22 May 2024 21:25:41 +0900

> I welcome feedback.  For some reason it was an easier job than usual.

Thanks for working on this as always.

<para>
Allow pg_stat_reset_shared("slru") to clear SLRU statistics (Atsushi 
Torikoshi)
</para>

Considering someone may copy and paste this, 'slru' is better than 
"slru", isn't it?
I also found an older release note[1] used single quotes for this like:

   Add pg_stat_reset_shared('bgwriter') to reset the cluster-wide shared 
statistics for the background writer (Greg Smith)

[1] https://www.postgresql.org/docs/release/9.0.0/

-- 
Regards,

--
Atsushi Torikoshi
NTT DATA Group Corporation

diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index 612eb100a7..96be7b3e8b 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -647,7 +647,7 @@ Author: Michael Paquier <[email-masked]>
 
 <listitem>
 <para>
-Allow pg_stat_reset_shared("slru") to clear SLRU statistics (Atsushi Torikoshi)
+Allow pg_stat_reset_shared('slru') to clear SLRU statistics (Atsushi Torikoshi)
 </para>
 
 <para>

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 22 May 2024 18:39:41 -0400

> The user can look at the documentation for comparison with libc.

Okay, changed with the attached applied patch.

  Only you can decide what is important to you.
diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index 3025f31f8a0..e381dbe5d96 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -885,11 +885,11 @@ Author: Jeff Davis <[email-masked]>
 
 <listitem>
 <para>
-Create "builtin" collation provider similar to libc's C locale (Jeff Davis)
+Add a builtin platform-independent collation provider (Jeff Davis)
 </para>
 
 <para>
-While its C locale is similar but independent of libc, its C.UTF-8 locale sorts by Unicode code points and has Unicode-based case folding.
+This supports "C" and "C.UTF-8" collations.
 </para>
 </listitem>

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 22 May 2024 18:46:53 -0400

> Alexander Korotkov, Andrew Dunstan, Amit Langote)

Thanks, applied.

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 22 May 2024 18:48:31 -0400

> I've attached a patch to fix it.

Agreed, applied, thanks.

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 22 May 2024 18:50:53 -0400

On Wed, May 22, 2024 at 09:25:41PM +0900, torikoshia wrote:
> Considering someone may copy and paste this, 'slru' is better than "slru",
> isn't it?

Agreed, patch applied, thanks.

---

From: Alvaro Herrera <[email-masked]>
Date: Thu, 23 May 2024 13:22:51 +0200

Hello,

Regarding this item

: Allow the SLRU cache sizes to be configured (Andrey Borodin, Dilip Kumar)
: 
: The new server variables are commit_timestamp_buffers,
: multixact_member_buffers, multixact_offset_buffers, notify_buffers,
: serializable_buffers, subtransaction_buffers, and transaction_buffers.

I hereby request to be listed as third author of this feature.

Also, I'd like to suggest to make it more verbose, as details might be
useful to users.  Mention that scalability is improved, because
previously we've suggested to recompile with larger #defines, but to be
cautious because values too high degrade performance.  Also mention the
point that some of these grow with shared_buffers is user-visible enough
that it warrants an explicit mention.  How about like this:

: Allow the SLRU cache sizes to be configured and improve performance of
: larger caches
: (Andrey Borodin, Dilip Kumar, Álvaro Herrera)
: 
: The new server variables are commit_timestamp_buffers,
: multixact_member_buffers, multixact_offset_buffers, notify_buffers,
: serializable_buffers, subtransaction_buffers, and transaction_buffers.
: commit_timestamp_buffers, transaction_buffers and
: subtransaction_buffers scale up automatically with shared_buffers.

These three items

: Allow pg_stat_reset_shared() to reset all shared statistics (Atsushi Torikoshi)
: 
: This is done by passing NULL.
: 
: Allow pg_stat_reset_shared('slru') to clear SLRU statistics (Atsushi Torikoshi)
: 
: Now pg_stat_reset_shared(NULL) also resets SLRU statistics.
: 
: Allow pg_stat_reset_slru() to reset all SLRU statistics (Bharath Rupireddy)
: 
: The command pg_stat_reset_slru(NULL) already did this.

seem a bit repetitive.  (I think the first one is also wrong, because it
says you have to pass NULL, but in reality you can also not give an
argument and it works.)  Can we make them a single item?  Maybe
something like

: Improve reset routines for shared statistics (Atsushi Torikoshi, Bharath Rupireddy)
:
: Resetting all shared statistics can now be done with
: pg_stat_reset_shared() or pg_stat_reset_shared(NULL), while SLRU
: statistics can now be reset with pg_stat_reset_shared('slru'),
: pg_stat_reset_slru() and pg_stat_reset_slru(NULL).

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Find a bug in a program, and fix it, and the program will work today.
Show the program how to find and fix a bug, and the program
will work forever" (Oliver Silfridge)

---

From: Jeff Davis <[email-masked]>
Date: Thu, 23 May 2024 08:30:25 -0700

> Okay, changed with the attached applied patch.

Thank you, looks good to me.

Regards,
	Jeff Davis

---

From: Marcos Pegoraro <[email-masked]>
Date: Thu, 23 May 2024 16:54:28 -0300

-

   Rename SLRU columns in system view pg_stat_slru (Alvaro Herrera)

   The column names accepted by pg_stat_slru_rest() are also changed.

Is pg_stat_slru_rest() correct ?

---

From: Peter Geoghegan <[email-masked]>
Date: Thu, 23 May 2024 20:19:15 -0400

> Agreed, patch applied, thanks.

The item for my commit 5bf748b8 currently reads:

"Allow btree indexes to more efficiently find array matches"

I think that this isn't likely to mean much to most users. It seems
like it'd be a lot clearer if the wording was more in line with the
beta1 announcement, which talks about the work as an enhancement to
index scans that use an IN ( ) condition. Specifically referencing
IN() (as opposed to something about arrays or array conditions) is
likely to make the item much more understandable.

Referencing array matches makes me think of a GIN index on an array
column. While ScalarArrayOps do use an array under the cover, that's
mostly an implementation detail. At least it is to users that
exclusively use IN(), likely the majority (that's the SQL standard
syntax).

For context, the Postgres 9.2 release notes described the feature that
my work directly built on as follows:

"Allow indexed_col op ANY(ARRAY[...]) conditions to be used in plain
index scans and index-only scans"

This was a very accurate description of this earlier work. Similar
wording could be used now, but that doesn't seem great to me either.
Simply because this wording also doesn't reference IN() conditions in
index quals.

-- 
Peter Geoghegan

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 25 May 2024 23:49:03 -0400

> : subtransaction_buffers scale up automatically with shared_buffers.

Yes, I like that, patch applied.

> : pg_stat_reset_slru() and pg_stat_reset_slru(NULL).

Andres already suggested improvement for this, and I posted the applied
patch.  Can you see if that is good or can be improved?  Thanks.

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 25 May 2024 23:50:34 -0400

On Thu, May 23, 2024 at 04:54:28PM -0300, Marcos Pegoraro wrote:
>   • Rename SLRU columns in system view pg_stat_slru (Alvaro Herrera)
> 

Oops, typo, fixed, thanks.

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 25 May 2024 23:57:01 -0400

> Simply because this wording also doesn't reference IN() conditions in

Agreed.  I changed it to:

	Allow btree indexes to more efficiently find a set of values, such as
	those supplied by IN subqueries

Is that good?

---

From: David Rowley <[email-masked]>
Date: Tue, 28 May 2024 14:44:28 +1200

>         those supplied by IN subqueries

I think this needs further adjustment.  An "IN subquery" is an IN
clause which contains a subquery.  As far as I understand it,
5bf748b86 does nothing to improve those. It's there to improve IN with
a set of values such as IN(1,2,3).

Maybe "IN subqueries" can be replaced with "an SQL IN clause".

David

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 28 May 2024 00:20:21 -0400

> Maybe "IN subqueries" can be replaced with "an SQL IN clause".

Okay, I went with:

	Allow btree indexes to more efficiently find a set of values,
	such as those supplied by IN clauses using constants (Peter Geoghegan,
	Matthias van de Meent)

---

From: Dean Rasheed <[email-masked]>
Date: Wed, 5 Jun 2024 23:46:17 +0100

>         https://momjian.us/pgsql_docs/release-17.html

I noticed a couple more things. This item:

  Add functions to convert integers to hex and binary strings

should read:

  Add functions to convert integers to binary and octal strings

The "Improve psql tab completion" item should include this commit:

Author: Michael Paquier <[email-masked]>
2024-05-01 [2800fbb2b] Add tab completion for EXPLAIN (MEMORY|SERIALIZE)

and credit Jian He.

Regards,
Dean

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 5 Jun 2024 20:53:09 -0400

Only you can decide what is important to you.
diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index 1131f2aab51..93bc7408b5b 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -1685,7 +1685,7 @@ Author: Nathan Bossart <[email-masked]>
 
 <listitem>
 <para>
-Add functions to convert integers to hex and binary strings (Eric Radman, Nathan Bossart)
+Add functions to convert integers to binary and octal strings (Eric Radman, Nathan Bossart)
 </para>
 
 <para>
@@ -2000,11 +2000,13 @@ Author: Masahiko Sawada <[email-masked]>
 2024-04-08 [304b6b1a6] Add more tab completion support for ALTER DEFAULT PRIVIL
 Author: Alexander Korotkov <[email-masked]>
 2024-04-30 [60ae37a8b] Add tab completion for partition MERGE/SPLIT operations
+Author: Michael Paquier <[email-masked]>
+2024-05-01 [2800fbb2b] Add tab completion for EXPLAIN (MEMORY|SERIALIZE)
 -->
 
 <listitem>
 <para>
-Improve psql tab completion (Dagfinn Ilmari Mannsåker, Gilles Darold, Christoph Heiss, Steve Chavez, Vignesh C, Pavel Borisov)
+Improve psql tab completion (Dagfinn Ilmari Mannsåker, Gilles Darold, Christoph Heiss, Steve Chavez, Vignesh C, Pavel Borisov, Jian He)
 </para>
 </listitem>

---

From: Matthias van de Meent <[email-masked]>
Date: Fri, 5 Jul 2024 19:51:38 +0200

Hi,

I noticed that PG17's release note for commit cafe10565 is "Allow psql
connections to be canceled with control-C (Tristan Partin)", but this
summary seems wrong to me.

We already had ^C connection (query) cancellation for quite some time
before this patch. What's new with that patch, is that we now also can
cancel connection attempts with ^C while we're still connecting (i.e.,
we haven't yet authenticated and are trying to move the connection
state forward).
I think a better wording would be "Allow psql connection attempts to
be canceled with control-C (Tristan Partin)", or "Allow psql
connections to be canceled with control-C while psql is still
connecting (Tristan Partin)".

Kind regards,

Matthias van de Meent
Neon (https://neon.tech)

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 5 Jul 2024 16:53:02 -0400

> connecting (Tristan Partin)".

I see your point.  I committed a change to use this wording:

      Allow psql connection attempts to be canceled with control-C
      (Tristan Partin)

---

From: Kisoon Kwon <[email-masked]>
Date: Wed, 17 Jul 2024 15:32:45 +0900

Hi,

In the PG17 release notes, I noticed it is mentioned as
"pg_attribute.stxstattarget" which seems incorrect.
In my opinion, it should be "pg_statistic_ext.stxstattarget" because the
"stxstattarget" column is part of the "pg_statistic_ext" catalog.

Regards,
Kisoon Kwon
Bitnine Global (www.bitnine.net)

---

From: Yugo Nagata <[email-masked]>
Date: Fri, 26 Jul 2024 13:22:24 +0900

Hi,

On Thu, 9 May 2024 00:03:50 -0400

> I welcome feedback.  For some reason it was an easier job than usual.

I found the following in the release notes:

 Change file boundary handling of two WAL file name functions 
 (Kyotaro Horiguchi, Andres Freund, Bruce Momjian)

 The functions pg_walfile_name() and pg_walfile_name_offset() used to report the previous 
 LSN segment number when  the LSN was on a file segment boundary; it now returns the LSN segment. 

It might be trivial, but, reading the associated commit message , I think it would be more explicit
for users to rewrite the last statement to

"it now returns the current LSN segment."

Regards,
Yugo Nagata

-- 
Yugo Nagata <[email-masked]>

---

From: Justin Pryzby <[email-masked]>
Date: Thu, 8 Aug 2024 08:55:53 -0500

> Add server variable huge_page_size to report the use of huge pages by

The new variable is huge_page_status; h_p_size is several years old.

BTW, I was surprised that these were included:

+2024-02-28 [363eb0599] Convert README to Markdown.
+2024-01-25 [7014c9a4b] Doc: improve documentation for jsonpath behavior.

-- 
Justin

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 16 Aug 2024 12:53:33 -0400

> "stxstattarget" column is part of the "pg_statistic_ext" catalog.

You are right, fixed in the attached patch.  Sorry for the delay.

  Only you can decide what is important to you.
diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index e9cee92ff44..dfbf8a74cd4 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -269,7 +269,7 @@ Author: Peter Eisentraut <[email-masked]>
      Change <link
      linkend="catalog-pg-attribute"><structname>pg_attribute</structname>.<structfield>attstattarget</structfield></link>
      and
-     <structname>pg_attribute</structname>.<structfield>stxstattarget</structfield>
+     <structname>pg_statistic_ext</structname>.<structfield>stxstattarget</structfield>
      to represent the default statistics target as <literal>NULL</literal>
      (Peter Eisentraut)
      </para>

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 16 Aug 2024 13:02:19 -0400

> "it now returns the current LSN segment."

Agreed, applied patch attached.  Sorry for the delay.

  Only you can decide what is important to you.
diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index dfbf8a74cd4..8a1e51f10d6 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -176,7 +176,7 @@ Author: Bruce Momjian <[email-masked]>
      and <function>pg_walfile_name_offset()</function> used to report
      the previous <acronym>LSN</acronym> segment number when the
      <acronym>LSN</acronym> was on a file segment boundary;  it now
-     returns the <acronym>LSN</acronym> segment.
+     returns the current <acronym>LSN</acronym> segment.
      </para>
     </listitem>

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 16 Aug 2024 13:20:28 -0400

> The new variable is huge_page_status; h_p_size is several years old.

Fixed.  I created this mistake when I was adding links to the SGML file.

> +2024-01-25 [7014c9a4b] Doc: improve documentation for jsonpath behavior.

I try to mention significant doc changes, and have done so in the past.

---

From: Nathan Bossart <[email-masked]>
Date: Tue, 3 Sep 2024 10:44:01 -0500

While freely acknowledging that I am biased because I wrote it, I am a bit
surprised to see the DSM registry left out of the release notes (commit
8b2bcf3, docs are here [0]).  This feature is intended to allow modules to
allocate shared memory after startup, i.e., without requiring the module to
be loaded via shared_preload_libraries.  IMHO that is worth mentioning.

[0] https://www.postgresql.org/docs/devel/xfunc-c.html#XFUNC-SHARED-ADDIN-AFTER-STARTUP

-- 
nathan

---

From: jian he <[email-masked]>
Date: Wed, 4 Sep 2024 19:18:52 +0800

hi.

Allow partitions to be merged using ALTER TABLE ... MERGE PARTITIONS
(Dmitry Koval)
Allow partitions to be split using ALTER TABLE ... SPLIT PARTITION
(Dmitry Koval)

also these two items got reverted? see
https://git.postgresql.org/cgit/postgresql.git/commit/?id=3890d90c1508125729ed20038d90513694fc3a7b

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 5 Sep 2024 21:49:48 -0400

> https://git.postgresql.org/cgit/postgresql.git/commit/?id=3890d90c1508125729ed20038d90513694fc3a7b

I don't see them in the PG 17 release notes at:

	https://www.postgresql.org/docs/17/release-17.html

I did just remove the tab complete comment for this though.

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 5 Sep 2024 21:51:25 -0400

> [0] https://www.postgresql.org/docs/devel/xfunc-c.html#XFUNC-SHARED-ADDIN-AFTER-STARTUP

That seems more infrastructure/extension author stuff which isn't
normally mentioned in the release notes.  I think such people really
need to look at all the commit messages.

---

From: Michael Banck <[email-masked]>
Date: Tue, 10 Sep 2024 09:11:19 +0200

On Thu, Sep 05, 2024 at 09:51:25PM -0400, Bruce Momjian wrote:
> normally mentioned in the release notes.

If I understand the feature correctly, it allows extensions to be just
CREATEd without having them to be added to shared_preload_libraries,
i.e. saving the organization an instance restart/downtime.

That seems important enough for end-users to know, even if they will
need to wait for extension authors to catch up to this (but I guess a
lot will).

Michael

---

From: Alvaro Herrera <[email-masked]>
Date: Wed, 11 Sep 2024 19:50:40 +0200

Hello,

I noticed that these two items in the current notes are separate:

<!--
Author: Alvaro Herrera <[email-masked]>
2024-03-25 [374c7a229] Allow specifying an access method for partitioned tables
Author: Alvaro Herrera <[email-masked]>
2024-03-28 [e2395cdbe] ALTER TABLE: rework determination of access method ID
-->

     <listitem>
      <para>
      Allow specification of partitioned <link linkend="tableam">table
      access methods</link> (Justin Pryzby, Soumyadeep Chakraborty,
      Michael Paquier)
      </para>
     </listitem>

<!--
Author: Michael Paquier <[email-masked]>
2024-03-08 [d61a6cad6] Add support for DEFAULT in ALTER TABLE .. SET ACCESS MET
-->

     <listitem>
      <para>
      Add <literal>DEFAULT</literal> setting for <literal>ALTER TABLE
      .. SET ACCESS METHOD</literal> (Michael Paquier)
      </para>
     </listitem>

They are very very closely related, so I suggest they should be
together as a single item.  Also, the first one is somewhat strangely
worded IMO (we don't have "partitioned table access methods" -- rather,
we have table access methods for partitioned tables).  Maybe something
like

* Improve ALTER TABLE ... SET ACCESS METHOD

  This command can now also be applied to partitioned tables, so that it
  can <link to "https://www.postgresql.org/docs/17/sql-altertable.html#SQL-ALTERTABLE-DESC-SET-ACCESS-METHOD">
  influence partitions created later</link>. (Justin, Soumyadeep, Michaël)

  In addition, it now accepts the value DEFAULT to reset a previously
  set value. (Michaël)

There's also a bunch of items on EXPLAIN, which could perhaps be grouped
in a single item with sub-paras for each individual change; I'd also
move it to the bottom of E.1.3.2.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"This is a foot just waiting to be shot"                (Andrew Dunstan)

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 13 Sep 2024 18:25:41 -0400

> we have table access methods for partitioned tables).  Maybe something

Yes, agree, the wording needs improvement, patch attached.

>   In addition, it now accepts the value DEFAULT to reset a previously

I moved the two items next to each other, but I am concerned combining
the partition feature with the DEFAULT features is just making it too
complicated to understand.

  When a patient asks the doctor, "Am I going to die?", he means 
  "Am I going to die soon?"
diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index 36e19bb8329..6d4ffa8ea1e 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -1659,23 +1659,6 @@ Author: Peter Eisentraut <[email-masked]>
       </para>
      </listitem>
 
-<!--
-Author: Alvaro Herrera <[email-masked]>
-2024-03-25 [374c7a229] Allow specifying an access method for partitioned tables
-Author: Alvaro Herrera <[email-masked]>
-2024-03-28 [e2395cdbe] ALTER TABLE: rework determination of access method ID
--->
-
-     <listitem>
-      <para>
-      Allow specification of partitioned <link linkend="tableam">table
-      access methods</link> (Justin Pryzby, Soumyadeep Chakraborty,
-      Michael Paquier)
-      <ulink url="&commit_baseurl;374c7a229">&sect;</ulink>
-      <ulink url="&commit_baseurl;e2395cdbe">&sect;</ulink>
-      </para>
-     </listitem>
-
 <!--
 Author: Peter Eisentraut <[email-masked]>
 2024-01-13 [4f622503d] Make attstattarget nullable
@@ -1714,6 +1697,23 @@ Author: Peter Eisentraut <[email-masked]>
       </para>
      </listitem>
 
+<!--
+Author: Alvaro Herrera <[email-masked]>
+2024-03-25 [374c7a229] Allow specifying an access method for partitioned tables
+Author: Alvaro Herrera <[email-masked]>
+2024-03-28 [e2395cdbe] ALTER TABLE: rework determination of access method ID
+-->
+
+     <listitem>
+      <para>
+      Allow specification of <link linkend="tableam">table access
+      methods</link> on partitioned tables (Justin Pryzby, Soumyadeep
+      Chakraborty, Michael Paquier)
+      <ulink url="&commit_baseurl;374c7a229">&sect;</ulink>
+      <ulink url="&commit_baseurl;e2395cdbe">&sect;</ulink>
+      </para>
+     </listitem>
+
 <!--
 Author: Michael Paquier <[email-masked]>
 2024-03-08 [d61a6cad6] Add support for DEFAULT in ALTER TABLE .. SET ACCESS MET

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 14 Sep 2024 09:38:46 -0400

> move it to the bottom of E.1.3.2.

Oh, I hadn't noticed I have five EXPLAIN items --- that is enough to
make a new section, done at:

	https://momjian.us/pgsql_docs/release-17.html#RELEASE-17-EXPLAIN

I don't think I can combine the EXPLAIN items without making them too
complex.

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Fri, 20 Sep 2024 10:02:25 -0400

> I welcome feedback.  For some reason it was an easier job than usual.

Attached is a proposal for the major features section. This borrows from 
the release announcement draft[1] and lists out features and themes that 
have broad user impact. This was a bit challenging for this release, 
because there are a lot of great features in PG17 that add up to a very 
special release.

Feedback welcome.

Thanks,

Jonathan

[1] 
https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=releases/17/release.en.md;hb=HEAD
diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index 9d69016cd6..7691ee3672 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -18,7 +18,62 @@
    </para>
 
    <itemizedlist>
-    <listitem><para>TO BE COMPLETED LATER</para></listitem>
+    <listitem>
+     <para>
+      New memory management system for <command>VACUUM</command>, which reduces
+      memory consumption and can improve overall vacuuming performance.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      New <acronym>SQL/JSON</acronym> capabilities, including constructors,
+      identity functions, and the <link
+      linkend="functions-sqljson-table"><function>JSON_TABLE()</function></link>
+      function, which converts JSON data into a table representation.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Various query performance improvements, including to sequential reads
+      using streaming I/O, write throughput under high concurrency, and
+      searches over multiple values in a <link linkend="btree">btree</link>
+      index.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Logical replication now supports failover control, and <link
+      linkend="pgupgrade"><application>pg_upgrade</application></link> now
+      preserves replications slots on both publishers and subscribers.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      New client-side connection option, <link
+      linkend="libpq-connect-sslnegotiation"><literal>sslnegotiation=direct</literal></link>,
+      that allows direct TLS handshakes that avoids a round-trip negotation.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      <link
+       linkend="app-pgbasebackup"><application>pg_basebackup</application></link>
+      now supports incremental backup.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      <link linkend="sql-copy"><command>COPY</command></link> adds a new option,
+      <literal>ON_ERROR ignore</literal>, that allows a copy operation to
+      continue in the event of an error.
+     </para>
+    </listitem>
    </itemizedlist>
 
    <para>

---

From: Laurenz Albe <[email-masked]>
Date: Fri, 20 Sep 2024 18:55:56 +0200

> because there are a lot of great features in PG17 that add up to a very 

I would have added the platform-independent binary collation provider.
And perhaps "pg_createsubscriber": that can be a game-changer for setting
up logical replication.

Yours,
Laurenz Albe

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Fri, 20 Sep 2024 13:47:43 -0400

> And perhaps "pg_createsubscriber": that can be a game-changer for setting

I was on the fence about that, mostly because it'd make that sentence 
too much of a mouthful, but I do agree.

IIRC (didn't get to check) we did have a precedent for sublists in the 
major features, so I broke this one up. Please see attached.

Jonathan

diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index 9d69016cd6..fdbbbed07a 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -18,7 +18,81 @@
    </para>
 
    <itemizedlist>
+      Logical replication enhancements, including:
+      <itemizedlist>
+         Failover control
+          linkend="app-pgcreatesubscriber"><application>pg_createsubscriber</application></link>,
+          a utility that logical replicas from physical standbys
+          preserves replication slots on both publishers and subscribers
+      </itemizedlist>
 
    <para>

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 20 Sep 2024 16:00:24 -0400

On Fri, Sep 20, 2024 at 01:47:43PM -0400, Jonathan Katz wrote:
> I was on the fence about that, mostly because it'd make that sentence too
> much of a mouthful, but I do agree.
> 
> IIRC (didn't get to check) we did have a precedent for sublists in the major
> features, so I broke this one up. Please see attached.

Patch applied to PG 17.

---

From: Tom Lane <[email-masked]>
Date: Fri, 20 Sep 2024 16:05:11 -0400

> Patch applied to PG 17.

I don't see a push?

			regards, tom lane

---

From: Laurenz Albe <[email-masked]>
Date: Fri, 20 Sep 2024 22:13:57 +0200

On Fri, 2024-09-20 at 13:47 -0400, Jonathan S. Katz wrote:
> Please see attached.

> +      searches over multiple values in a <link linkend="btree">btree</link>

Perhaps that last part could be "and searches over IN-lists in a b-tree index".
It might be technically less correct, but I'd expect that it gives more people
the right idea.

> +          a utility that logical replicas from physical standbys

There's a verb missing: "a utility that *creates* logical replicas..."

> +          preserves replication slots on both publishers and subscribers

I wonder if we should omit "on both publishers and subscribers".
It preserves replication slots anywhere, right?

> +      that allows direct TLS handshakes that avoids a round-trip negotation.

It should be "that avoid".  Plural.

Yours,
Laurenz Albe

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 20 Sep 2024 16:20:04 -0400

> Bruce Momjian <[email-masked]> writes:

Push was delayed because my test script found some uncommitted files due
to earlier testing.  Should be fine now.

---

From: Tom Lane <[email-masked]>
Date: Fri, 20 Sep 2024 16:21:13 -0400

Laurenz Albe <[email-masked]> writes:
> [ assorted corrections ]

I fixed a couple of these before seeing your message.

			regards, tom lane

---

From: Yugo Nagata <[email-masked]>
Date: Thu, 26 Sep 2024 14:19:21 +0900

> I have committed the first draft of the PG 17 release notes;  you can

I propose to improve the following description in "Migration to Version 17"
section by adding CREATE INDEX and CREATE MATERIALIZED VIEW into the command list.

     <para>
     Change functions to use a safe <xref linkend="guc-search-path"/>
     during maintenance operations (Jeff Davis)
     <ulink url="&commit_baseurl;2af07e2f7">&sect;</ulink>
     </para>

It is suggested in the thread [1] that users could not notice the behaviour
of CREATE INDEX is changed because the explicit command name is not listed in
the release notes. So, I think it is better to add CREATE INDEX and
CREATE MATERIALIZED VIEW into the command list. 

I've attached a patch.

[1] https://www.postgresql.org/message-id/flat/20240926125110.67e52f4f7a388af539367213%40sraoss.co.jp#71d4b5d6c842ba038e1e4e99c110b688

-- 
Yugo Nagata <[email-masked]>
diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index ad81473774..085ca6bbc6 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -136,7 +136,8 @@ Author: Jeff Davis <[email-masked]>
 
      <para>
      This prevents maintenance operations (<command>ANALYZE</command>,
-     <command>CLUSTER</command>, <command>REFRESH
+     <command>CLUSTER</command>, <command>CREATE INDEX</command>,
+     <command>CREATE MATERIALIZED VIEW</command>, <command>REFRESH
      MATERIALIZED VIEW</command>, <command>REINDEX</command>,
      or <command>VACUUM</command>) from performing unsafe access.
      Functions used by expression indexes and materialized views that

---

From: Amit Kapila <[email-masked]>
Date: Thu, 26 Sep 2024 15:08:52 +0530

> to earlier testing.  Should be fine now.

<para>
         <link
          linkend="app-pgcreatesubscriber"><application>pg_createsubscriber</application></link>,
          a utility that creates logical replicas from physical standbys
        </para>

This description is okay but according to me, the more compelling use
case is that this new utility helps to allow online upgrades of
physical replication setup as explained in the blog [1]. See the
section: "Upgrading Streaming (Physical) Replication Setup".

       </listitem>
       <listitem>
        <para>
         <link
          linkend="pgupgrade"><application>pg_upgrade</application></link> now
          preserves replication slots on both publishers and subscribers
        </para>

It is better to write the above statement as:
"pg_upgrade</application></link> now preserves replication slots on
publishers and full subscription's state on subscribers". This is
because replication slots are preserved on publishers. The subscribers
preserve the subscription state.

[1] - http://amitkapila16.blogspot.com/2024/09/online-upgrading-logical-and-physical.html

-- 
With Regards,
Amit Kapila.

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 28 Sep 2024 21:19:11 -0400

> CREATE MATERIALIZED VIEW into the command list. 

It this a valid change?  Seems so.

---

From: Yugo NAGATA <[email-masked]>
Date: Mon, 30 Sep 2024 14:20:21 +0900

On Sat, 28 Sep 2024 21:19:11 -0400

> It this a valid change?  Seems so.

Yes. This change on CREATE INDEX was introduced by 2af07e2f7 together with
other commands, but it was missed to be mentioned in the commit message
although the description was added to the documentation.

The change on CEATE MATERIALIZED VIEW was introduced by a separate commit
b4da732fd, since which the REFRESH logic is used when creating a matview.
Should we add here a link to that commit, too?

Regards,
Yugo Nagata

-- 
Yugo NAGATA <[email-masked]>

---

From: Laurenz Albe <[email-masked]>
Date: Tue, 01 Oct 2024 16:36:09 +0200

I think that the removal of the "adminpack" extension should
be listed in the section "migration to v17" as an incompatibility.

I have seen one complaint that pg_upgrade fails if the extension
is installed, but a dump/restore would also throw an error.

Yours,
Laurenz Albe
From bab39739eb13f57572b76c4bd3fca3f16713da63 Mon Sep 17 00:00:00 2001
From: Laurenz Albe <[email-masked]>
Date: Tue, 1 Oct 2024 16:33:40 +0200
Subject: [PATCH v1] doc PG relnotes:  list adminpack removal as
 incompatibility

You have to drop the extension before you can upgrade.
---
 doc/src/sgml/release-17.sgml | 37 ++++++++++++++++++------------------
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index ad814737745..1ff572f8271 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -421,6 +421,25 @@ Author: Alvaro Herrera <[email-masked]>
      </para>
     </listitem>
 
+<!--
+Author: Daniel Gustafsson <[email-masked]>
+2024-03-04 [cc09e6549] Remove the adminpack contrib extension
+-->
+
+     <listitem>
+      <para>
+      Remove <application>adminpack</application> contrib extension
+      (Daniel Gustafsson)
+      <ulink url="&commit_baseurl;cc09e6549">&sect;</ulink>
+      </para>
+
+      <para>
+      This was used by now end-of-life <productname>pgAdmin
+      III</productname>.  You need to drop the extension before you
+      can upgrade to version 17.
+      </para>
+     </listitem>
+
    </itemizedlist>
 
   </sect2>
@@ -3302,24 +3321,6 @@ Author: Nathan Bossart <[email-masked]>
       </para>
      </listitem>
 
-<!--
-Author: Daniel Gustafsson <[email-masked]>
-2024-03-04 [cc09e6549] Remove the adminpack contrib extension
--->
-
-     <listitem>
-      <para>
-      Remove <application>adminpack</application> contrib extension
-      (Daniel Gustafsson)
-      <ulink url="&commit_baseurl;cc09e6549">&sect;</ulink>
-      </para>
-
-      <para>
-      This was used by now end-of-life <productname>pgAdmin
-      III</productname>.
-      </para>
-     </listitem>
-
 <!--
 Author: Tom Lane <[email-masked]>
 2023-10-20 [2b5154bea] Extend ALTER OPERATOR to allow setting more optimization
-- 
2.46.2

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 7 Oct 2024 19:25:11 -0400

> Should we add here a link to that commit, too?

I developed the attached patch which adds the two commands and the
commit item.

  When a patient asks the doctor, "Am I going to die?", he means 
  "Am I going to die soon?"
diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index ad814737745..7acdee05e42 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -125,6 +125,8 @@
 <!--
 Author: Jeff Davis <[email-masked]>
 2024-03-04 [2af07e2f7] Fix search_path to a safe value during maintenance opera
+Author: Jeff Davis <[email-masked]>
+2024-07-16 [b4da732fd64] When creating materialized views, use REFRESH to load data.
 -->
 
     <listitem>
@@ -136,7 +138,9 @@ Author: Jeff Davis <[email-masked]>
 
      <para>
      This prevents maintenance operations (<command>ANALYZE</command>,
-     <command>CLUSTER</command>, <command>REFRESH
+     <command>CLUSTER</command>, <command>CREATE
+     INDEX</command>, <command>CREATE
+     MATERIALIZED VIEW</command>, <command>REFRESH
      MATERIALIZED VIEW</command>, <command>REINDEX</command>,
      or <command>VACUUM</command>) from performing unsafe access.
      Functions used by expression indexes and materialized views that

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 7 Oct 2024 20:00:45 -0400

> I developed the attached patch which adds the two commands and the

Okay, updated commit after running src/tools/add_commit_links.pl.

index ad814737745..0ea9d96a47f 100644
 
     <listitem>
@@ -132,11 +134,14 @@ Author: Jeff Davis <[email-masked]>
      Change functions to use a safe <xref linkend="guc-search-path"/>
      during maintenance operations (Jeff Davis)
      <ulink url="&commit_baseurl;2af07e2f7">&sect;</ulink>
+     <ulink url="&commit_baseurl;b4da732fd64">&sect;</ulink>
      </para>
 
      <para>

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 7 Oct 2024 20:11:37 -0400

> is installed, but a dump/restore would also throw an error.

Agreed. moved.

---

From: Laurenz Albe <[email-masked]>
Date: Tue, 08 Oct 2024 08:36:43 +0200

> > is installed, but a dump/restore would also throw an error.

Thank you!

Yours,
Laurenz Albe

---

From: Yugo NAGATA <[email-masked]>
Date: Tue, 8 Oct 2024 19:51:23 +0900

On Mon, 7 Oct 2024 20:00:45 -0400

> Okay, updated commit after running src/tools/add_commit_links.pl.

LGTM. Thank you.

Regards,
Yugo Nagata

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 9 Oct 2024 22:58:19 -0400

> > Okay, updated commit after running src/tools/add_commit_links.pl.

Thanks, patch applied.