Re: could not read from hash-join temporary file: SUCCESS && DB goes into recovery mode - Mailing list pgsql-general

From Tom Lane
Subject Re: could not read from hash-join temporary file: SUCCESS && DB goes into recovery mode
Date
Msg-id 208065.1618840431@sss.pgh.pa.us
Whole thread Raw
In response to could not read from hash-join temporary file: SUCCESS && DB goes into recovery mode  (Reid Thompson <Reid.Thompson@omnicell.com>)
Responses RE: could not read from hash-join temporary file: SUCCESS && DB goes into recovery mode  (Reid Thompson <Reid.Thompson@omnicell.com>)
List pgsql-general
Reid Thompson <Reid.Thompson@omnicell.com> writes:
> Hi I'm looking for some guidance related to the subject line issue.

Is this repeatable?  If so you've found a bug, I think.

>   1.  That the error message has been updated ( i.e. SUCCESS is not the proper value)

Yeah, what this really indicates is an incomplete read (file shorter than
expected).  Since 11.8, we've improved the error reporting for that, but
that wouldn't in itself fix whatever the underlying problem is.

>   2.  That the error is due to running out of temporary space either disk space or maybe temp_buffers?

That could be the proximate cause, although then there would be a bug
that the original write failure wasn't detected.  But it seems about
as likely that there's just some inconsistency between what the temp
file writing code wrote and what the reading code expects to read.

Is this a parallelized hash join by any chance?  That's new in v11
if memory serves, so it'd be interesting to see if disabling
enable_parallel_hash changes anything.

Anyway, I'd counsel updating to current (11.11), and then if you can
still reproduce the problem, try to reduce it to a self-contained
test case.

            regards, tom lane



pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Question about contrib
Next
From: Tom Lane
Date:
Subject: Re: postgres in container, redirect csvlog to stderr