Feedback-ID: ia2694551:Fastmail
Date: Sun, 5 Feb 2023 13:10:47 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: First draft of back-branch release notes is done
Message-ID: <20230205121047.hfjbdc7s36aiesbm@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1718789.1675452759@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/20230205121047.hfjbdc7s36aiesbm%40alvherre.pgsql>
Precedence: bulk

On 2023-Feb-03, Tom Lane wrote:

> ... at
> 
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f282b026787da69d88a35404cf62f1cc21cfbb7c
> 
> 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)