Subject: First draft of back-branch release notes is done

From: Tom Lane <[email-masked]>
Date: Fri, 03 Feb 2023 14:32:39 -0500

... at

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f282b026787da69d88a35404cf62f1cc21cfbb7c

As usual, please send corrections/comments by Sunday.

			regards, tom lane

---

From: Alvaro Herrera <[email-masked]>
Date: Sun, 5 Feb 2023 13:10:47 +0100

> As usual, please send corrections/comments by Sunday.

      Fix edge-case data corruption in shared tuplestores (Dmitry Astapov)

      If the final chunk of a large tuple being written out to disk was
      exactly 32760 bytes, it would be corrupted due to a fencepost bug.
      This is a hazard for parallelized plans that require a tuplestore,
      such as parallel hash join.  The query would typically fail later
      with corrupted-data symptoms.

I think this sounds really scary, because people are going to think that
their stored data can get corrupted -- they don't necessarily know what
a "shared tuplestore" is.  Maybe "Avoid query failures in parallel hash
joins" as headline?

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"The Gord often wonders why people threaten never to come back after they've
been told never to return" (www.actsofgord.com)

---

From: Tom Lane <[email-masked]>
Date: Sun, 05 Feb 2023 14:57:39 -0500

> a "shared tuplestore" is.  Maybe "Avoid query failures in parallel hash

Hmmm ... are we sure it *can't* lead to corruption of stored data,
if this happens during an INSERT or UPDATE plan?  I'll grant that
such a case seems pretty unlikely though, as the bogus data
retrieved from the tuplestore would have to not cause a failure
within the query before it can get written out.

Also, aren't shared tuplestores used in more places than just
parallel hash join?  I mentioned that as an example, not an
exhaustive list of trouble spots.

			regards, tom lane

---

From: Justin Pryzby <[email-masked]>
Date: Wed, 8 Feb 2023 16:08:35 -0600

> As usual, please send corrections/comments by Sunday.

It's of no concern, but I was curious why this one wasn't included:

commit 72aea955d49712a17c08748aa9abcbcf98c32fc5
Author: Thomas Munro <[email-masked]>
Date:   Fri Jan 6 16:38:46 2023 +1300

    Fix pg_truncate() on Windows.
    
    Commit 57faaf376 added pg_truncate(const char *path, off_t length), but
    "length" was ignored under WIN32 and the file was unconditionally
    truncated to 0.
    
    There was no live bug, since the only caller passes 0.
    
    Fix, and back-patch to 14 where the function arrived.