]> granicus.if.org Git - postgresql/commit
Have BufFileSize() ereport() on FileSize() failure.
authorPeter Geoghegan <pg@bowt.ie>
Wed, 28 Nov 2018 22:42:52 +0000 (14:42 -0800)
committerPeter Geoghegan <pg@bowt.ie>
Wed, 28 Nov 2018 22:42:52 +0000 (14:42 -0800)
commit95c45718126fe081e9236335a85d15ad24adc107
treeb4e7a4f5bc32d7ddb2cc5253e96ac7d9e145ad29
parent48cf9184ce9574363b310eaf65c7c939a5d40e76
Have BufFileSize() ereport() on FileSize() failure.

Move the responsibility for checking for and reporting a failure from
the only current BufFileSize() caller, logtape.c, to BufFileSize()
itself.  Code within buffile.c is generally responsible for interfacing
with fd.c to report irrecoverable failures.  This seems like a
convention that's worth sticking to.

Reorganizing things this way makes it easy to make the error message
raised in the event of BufFileSize() failure descriptive of the
underlying problem.  We're now clear on the distinction between
temporary file name and BufFile name, and can show errno, confident that
its value actually relates to the error being reported.  In passing, an
existing, similar buffile.c ereport() + errcode_for_file_access() site
is changed to follow the same conventions.

The API of the function BufFileSize() is changed by this commit, despite
already being in a stable release (Postgres 11).  This seems acceptable,
since the BufFileSize() ABI was changed by commit aa551830421, which
hasn't made it into a point release yet.  Besides, it's difficult to
imagine a third party BufFileSize() caller not just raising an error
anyway, since BufFile state should be considered corrupt when
BufFileSize() fails.

Per complaint from Tom Lane.

Discussion: https://postgr.es/m/26974.1540826748@sss.pgh.pa.us
Backpatch: 11-, where shared BufFiles were introduced.
src/backend/storage/file/buffile.c
src/backend/utils/sort/logtape.c