Currently, in places like heap_drop_with_catalog, we issue a
FlushRelationBuffers() call followed by smgrscheduleunlink().
The latter doesn't actually do anything right away, but schedules
a file unlink to occur after transaction commit.
It strikes me that the FlushRelationBuffers call is unnecessary and
causes useless I/O, namely writing out pages into a file that's
about to be deleted anyway. If we simply removed it then any buffers
belonging to the victim relation would stay in memory until commit;
then they'd be dropped *without* write by the smgr unlink operation
(which already calls DropRelFileNodeBuffers).
This doesn't cause any problems with rolling back the transaction before
commit; we can perfectly well leave dirty pages in the buffer pool in
that case. About the only downside I can see is that the Flush allows
buffer pages to be freed slightly sooner, and hence possibly used for
something else later in the same transaction ... but that's hardly worth
the cost of writing data that might not need to be written at all.
Similar remarks apply to the partial FlushRelationBuffers calls that are
currently done just before partial or full truncation of a relation ---
except that those are even sillier, because we are writing data that we
are definitely going to tell the kernel to forget about immediately
afterward. We should just drop any buffers that are past the truncation
point. smgrtruncate isn't roll-back-able anyway, so the caller already
has to be certain that the pages aren't going to be needed anymore
regardless of any subsequent rollback.
Can anyone see a flaw in this logic?
I think that the FlushRelationBuffers calls associated with deletion
are leftover from a time when we actually deleted the target file
immediately (ie, back when DROP TABLE wasn't rollback-safe). The
ones associated with truncation were probably just modeled on the
deletion logic without sufficient thought.
regards, tom lane