From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: First draft of back-branch release notes is done
In-reply-to: <20230205121047.hfjbdc7s36aiesbm@alvherre.pgsql>
References: <20230205121047.hfjbdc7s36aiesbm@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
	message dated "Sun, 05 Feb 2023 13:10:47 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2521819.1675627059.1@sss.pgh.pa.us>
Date: Sun, 05 Feb 2023 14:57:39 -0500
Message-ID: <2521820.1675627059@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/2521820.1675627059%40sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2023-Feb-03, Tom Lane wrote:
>>       Fix edge-case data corruption in shared tuplestores (Dmitry Astapov)

> 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?

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