RE: could not read from hash-join temporary file: SUCCESS && DB goes into recovery mode

From: Reid Thompson <Reid(dot)Thompson(at)omnicell(dot)com>
To: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Cc: Reid Thompson <Reid(dot)Thompson(at)omnicell(dot)com>
Subject: RE: could not read from hash-join temporary file: SUCCESS && DB goes into recovery mode
Date: 2021-04-19 15:12:33
Message-ID: SJ0PR11MB4848E96A73B49F5A63C57A259E499@SJ0PR11MB4848.namprd11.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thanks - I found that, which seems to fix the error handling right? Or does it actually correct the cause of the segfault also?
Any suggestion on how to avoid the error until we can schedule an upgrade?
Would increasing temp_buffers or some other setting for this query potentially avoid the issue until then?

-----Original Message-----
From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Sent: Monday, April 19, 2021 10:09 AM
To: Reid Thompson <Reid(dot)Thompson(at)omnicell(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: could not read from hash-join temporary file: SUCCESS && DB goes into recovery mode

[EXTERNAL SOURCE]

On 2021-Apr-19, Reid Thompson wrote:

> Hi I'm looking for some guidance related to the subject line issue.
> PostgreSQL 11.8 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5
> 20150623 (Red Hat 4.8.5-39), 64-bit 128GB RAM pgsql_tmp is on a FS
> with 2+TB free

This bug report looks familiar. I think it was fixed in the below commit and that you'd benefit from running an up-to-date version (11.11).

Author: Thomas Munro <tmunro(at)postgresql(dot)org>
Branch: master [7897e3bb9] 2020-06-16 16:59:07 +1200
Branch: REL_13_STABLE Release: REL_13_0 [3e0b08c40] 2020-06-16 17:00:06 +1200
Branch: REL_12_STABLE Release: REL_12_4 [28ee12669] 2020-06-16 17:00:21 +1200
Branch: REL_11_STABLE Release: REL_11_9 [9c14d6024] 2020-06-16 17:00:37 +1200
Branch: REL_10_STABLE Release: REL_10_14 [95647a1c7] 2020-06-16 17:00:53 +1200
Branch: REL9_6_STABLE Release: REL9_6_19 [02b71f06b] 2020-06-16 17:01:07 +1200
Branch: REL9_5_STABLE Release: REL9_5_23 [89020a92f] 2020-06-16 17:01:22 +1200

Fix buffile.c error handling.

Convert buffile.c error handling to use ereport. This fixes cases where
I/O errors were indistinguishable from EOF or not reported. Also remove
"%m" from error messages where errno would be bogus. While we're
modifying those strings, add block numbers and short read byte counts
where appropriate.

Back-patch to all supported releases.

Reported-by: Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>
Reviewed-by: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Reviewed-by: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Reviewed-by: Robert Haas <robertmhaas(at)gmail(dot)com>
Reviewed-by: Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>
Reviewed-by: Michael Paquier <michael(at)paquier(dot)xyz>
Discussion: https://urldefense.com/v3/__https://postgr.es/m/CA*2BhUKGJE04G*3D8TLK0DLypT_27D9dR8F1RQgNp0jK6qR0tZGWOw*40mail.gmail.com__;JSUl!!N6reDgEgb0HY4g!zaSosN1AQwgx5QR6S1H3a3cbt_0DC3yUUvi9IgYNtSVGRz3V_ZP697VcI9_USNGGGu8C$

--
Álvaro Herrera 39°49'30"S 73°17'W
EnterpriseDB https://urldefense.com/v3/__https://www.enterprisedb.com__;!!N6reDgEgb0HY4g!zaSosN1AQwgx5QR6S1H3a3cbt_0DC3yUUvi9IgYNtSVGRz3V_ZP697VcI9_USHTtYxZZ$

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alvaro Herrera 2021-04-19 15:59:28 Re: could not read from hash-join temporary file: SUCCESS && DB goes into recovery mode
Previous Message Mohan Radhakrishnan 2021-04-19 14:54:57 Re: Storing state machine