On Wed, Jan 25, 2017 at 3:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Um, I didn't find it all that self-explanatory. Why wouldn't we want
> to avoid writing undefined data?
For roughly the same reason we'd want to avoid it in existing cases
that are next to the proposed new suppression. We happen to not need
to initialize the data, but the interface we're using still requires
that we write at a coarser granularity than bytes. logtape.c always
writes whole blocks at a time.
> Also, the suppression seems far too broad. It would for instance
> block any complaint about a write() invoked via an elog call from
> any function invoked from any LogicalTape* function, no matter
> how far removed.
Writing blocks doesn't just happen in what tuplesort.c or even
logtape.c would consider to be a write path -- it happens when
logtape.c has a dirty buffer that it cleans. Plus you have double
buffering here -- buffile.c manages its own BLCKSZ buffer at the end
of the BufFile struct.
IIRC the reason I did things this way is because both
LogicalTapeRead() and LogicalTapeWrite() both appeared in offending
stack traces, and ltsWriteBlock() would not have plugged that, because
ltsReadBlock() could be involved instead. I don't remember the exact
details offhand, so I will have to look into it again.
--
Peter Geoghegan
