Re: First draft of PG 17 release notes - Mailing list pgsql-hackers

On Fri, May 10, 2024 at 06:50:54PM +0200, Jelte Fennema-Nio wrote:
> On Thu, 9 May 2024 at 06:04, Bruce Momjian <bruce@momjian.us> wrote:
> >
> > 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
> 
> 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):

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 <drowley@postgresql.org>
    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/CAGPVpCR15nosj0f6xe-c2h477zFR88q12e6WjEoEZc8ZYkTh3Q@mail.gmail.com

> - cafe1056558fe07cdc52b95205588fcd80870362

    commit cafe1056558
    Author: Robert Haas <rhaas@postgresql.org>
    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/D08WWCPVHKHN.3QELIKZJ2D9RZ@neon.tech

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

  Only you can decide what is important to you.