On 06/10/2026 16:10, Jakub Wartak wrote:
> further more sendFile() has this too above the "if (cnt < BLCKSZ)"
> /*
> * If we get a partial read, that must mean that the relation is
> * being truncated. Ultimately, it should be truncated to a
> * multiple of BLCKSZ, since this path should only be reached for
> * relation files, but we might transiently observe an
> * intermediate value.
> *
> * It should be fine to treat this just as if the entire block had
> * been truncated away - i.e. fill this and all later blocks with
> * zeroes. WAL replay will fix things up.
> */
>
> and below that, there is ereport() that says just checksums couldn't be
> verified. I mean in 0004 we are just growing and so it assumes we shouldn't
> get any problems with this code. It looks like it is written while expecting
> proper pread()/pwrite() atomicity when extending for up to 32kb, or am I
> missing something?
I think that comment is wrong. A short read is possible for other
reasons than a truncated file, e.g. if the read is interrupted by a
signal. In the past, we've made that same assumption that you never get
a short read on a BLCKSZ-sized read in other places too, but it was
always questionable. Thomas Munro fixed it for smgrread() in commit
4908c58720.
I think we should now fix that in read_file_data_into_buffer(), too.
Make it retry, so that it never returns fewer bytes than requested
except for EOF. With a larger buffer, a short read becomes more likely.
- Heikki
