On Wed, Jan 25, 2017 at 3:16 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers