Re: Assertion failure with barriers in parallel hash join - Mailing list pgsql-hackers

From David Geier
Subject Re: Assertion failure with barriers in parallel hash join
Date
Msg-id ea970eb3-f645-5d17-7e67-285a41a064b8@gmail.com
Whole thread Raw
In response to Re: Assertion failure with barriers in parallel hash join  (David Geier <geidav.pg@gmail.com>)
Responses Re: Assertion failure with barriers in parallel hash join
List pgsql-hackers

Hi Thomas,

Can we make progress with this patch in the current commit fest, or discuss what is still missing to bring this in?

Thanks!

--
David Geier
(ServiceNow)

On 6/6/22 17:01, David Geier wrote:
Hi Thomas,

Correct. We're running with disabled parallel leader participation and we have to do so, because another custom plan node we built relies on that.
That would be great. Anything else I can help with to get this patch in?

Thanks!

--
David
(ServiceNow)

On Fri, 3 Jun 2022 at 00:06, Thomas Munro <thomas.munro@gmail.com> wrote:
On Thu, Jun 2, 2022 at 9:31 PM David Geier <geidav.pg@gmail.com> wrote:
> We recently encountered the same bug in the field. Oleksii Kozlov managed to come up with reproduction steps, which reliably trigger it. Interestingly, the bug does not only manifest as failing assertion, but also as segmentation fault; in builds with disabled and with enabled (!) assertions. So it can crash production environments. We applied the proposed patch v3 from Melanie to the REL_14_3 branch and can confirm that with the patch neither the assertion nor the segmentation fault still occur.

Thanks for the report, testing, and for creating the CF entry.

I assume you are using parallel_leader_participation=off, and the
reason we haven't heard more about this is because few people do that.
By coincidence I was just about to restart a bunch of hash join
projects and have been paging the topic area back into my brain, so
I'll start with another round of testing/analysis of this bug/patch
next week.

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Fix order of checking ICU options in initdb and create database
Next
From: Japin Li
Date:
Subject: Typo for xl_running_xacts