1
0
mirror of https://github.com/postgres/postgres.git synced 2025-11-19 13:42:17 +03:00

Improve tuplestore's error messages for I/O failures.

We should report the errno when we get a failure from functions like
BufFileWrite.  "ERROR: write failed" is unreasonably taciturn for a
case that's well within the realm of possibility; I've seen it a
couple times in the buildfarm recently, in situations that were
probably out-of-disk-space, but it'd be good to see the errno
to confirm it.

I think this code was originally written without assuming that
the buffile.c functions would return useful errno; but most other
callers *are* assuming that, and a quick look at the buffile code
gives no reason to suppose otherwise.

Also, a couple of the old messages were phrased on the assumption
that a short read might indicate a logic bug in tuplestore itself;
but that code's pretty well tested by now, so a filesystem-level
problem seems much more likely.
This commit is contained in:
Tom Lane
2014-06-12 18:59:06 -04:00
parent 70ad7ed4e8
commit 6554656ea2
2 changed files with 47 additions and 22 deletions

View File

@@ -208,11 +208,9 @@ ltsWriteBlock(LogicalTapeSet *lts, long blocknum, void *buffer)
if (BufFileSeekBlock(lts->pfile, blocknum) != 0 ||
BufFileWrite(lts->pfile, buffer, BLCKSZ) != BLCKSZ)
ereport(ERROR,
/* XXX is it okay to assume errno is correct? */
(errcode_for_file_access(),
errmsg("could not write block %ld of temporary file: %m",
blocknum),
errhint("Perhaps out of disk space?")));
blocknum)));
}
/*
@@ -227,7 +225,6 @@ ltsReadBlock(LogicalTapeSet *lts, long blocknum, void *buffer)
if (BufFileSeekBlock(lts->pfile, blocknum) != 0 ||
BufFileRead(lts->pfile, buffer, BLCKSZ) != BLCKSZ)
ereport(ERROR,
/* XXX is it okay to assume errno is correct? */
(errcode_for_file_access(),
errmsg("could not read block %ld of temporary file: %m",
blocknum)));