On Wed, May 27, 2020 at 1:30 PM Tom Lane wrote:
> Alvaro Herrera writes:
> > There are more uses of BufFileRead that don't bother to distinguish
> > these two cases apart, though -- logtape.c, tuplestore.c,
> > gistbuildbuffers.c all do the same.
>
> Yeah. I rather suspect that callers of BufFil
Alvaro Herrera writes:
> There are more uses of BufFileRead that don't bother to distinguish
> these two cases apart, though -- logtape.c, tuplestore.c,
> gistbuildbuffers.c all do the same.
Yeah. I rather suspect that callers of BufFileRead/Write are mostly
expecting that those functions will t
On 2020-May-26, Tom Lane wrote:
> Are you sure you correctly identified the source of the bogus error
> report?
This version's better. It doesn't touch the write side at all.
On the read side, only report a short read as such if errno's not set.
This error isn't frequently seen. This page
http
On 2020-May-26, Tom Lane wrote:
> Digging further down, it looks like BufFileWrite calls BufFileDumpBuffer
> which calls FileWrite which takes pains to set errno correctly after a
> short write --- so other than the lack of commentary about these
> functions' error-reporting API, I don't think the
Alvaro Herrera writes:
> Hmm, right -- I was extending the partial read case to apply to a
> partial write, and we deal with those very differently. I changed the
> write case to use our standard approach.
Actually ... looking more closely, this proposed change in
ExecHashJoinSaveTuple flat out
Hi Tom, thanks for looking.
On 2020-May-25, Tom Lane wrote:
> I don't mind if you want to extend that paradigm to also use "wrote only
> %d bytes" wording, but the important point is to get the SQLSTATE set on
> the basis of ENOSPC rather than whatever random value errno will have
> otherwise.
H
Alvaro Herrera writes:
> I recently noticed this in a customer log file:
> ERROR: could not read from hash-join temporary file: Success
> The problem is we're reporting with %m when the problem is a partial
> read or write.
> I propose the attached patch to solve it: report "wrote only X of X
>
I recently noticed this in a customer log file:
ERROR: could not read from hash-join temporary file: Success
The problem is we're reporting with %m when the problem is a partial
read or write.
I propose the attached patch to solve it: report "wrote only X of X
bytes". This caused a lot of oth
