From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: hash join error improvement (old) |
Date: | 2020-05-26 14:43:31 |
Message-ID: | 17635.1590504211@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> 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 doesn't work, because it assumes that
BufFileWrite reports errors the same way as write(), which is not the
case. In particular, written < 0 can't happen; moreover, you've
removed detection of a short write as opposed to a completely failed
write.
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 there's any actual bug here.
Are you sure you correctly identified the source of the bogus error
report?
Similarly, I'm afraid you introduced rather than removed problems
in ExecHashJoinGetSavedTuple. BufFileRead doesn't use negative
return values either.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Guillaume Lelarge | 2020-05-26 14:44:59 | Re: Default gucs for EXPLAIN |
Previous Message | Stephen Frost | 2020-05-26 14:35:01 | Re: Default gucs for EXPLAIN |