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@xxxxxxxxxxxxxx>
Sent: Monday, April 19, 2021 10:09 AM
To: Reid Thompson <Reid.Thompson@xxxxxxxxxxxx>
Cc: pgsql-general@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxx>
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.pg@xxxxxxxxx>
Reviewed-by: Melanie Plageman <melanieplageman@xxxxxxxxx>
Reviewed-by: Alvaro Herrera <alvherre@xxxxxxxxxxxxxxx>
Reviewed-by: Robert Haas <robertmhaas@xxxxxxxxx>
Reviewed-by: Ibrar Ahmed <ibrar.ahmad@xxxxxxxxx>
Reviewed-by: Michael Paquier <michael@xxxxxxxxxxx>
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$
