I wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Could we avoid this
>> altogether by allocating a new relfilenode on truncate?
> Then we'd have to copy all the data we *didn't* truncate, which is
> hardly likely to be a win.
There is one thing we could do pretty easily. AFAICS there are
presently just two users of smgrtruncate: vacuumlazy.c and
heap_truncate. The latter is used primarily for ON COMMIT DELETE ROWS.
AFAICS we could still use drop-dirty-buffers semantics for that.
In event of a truncate failure, we'd have garbage data on disk,
but it doesn't matter because that data would represent rows inserted
by the transaction that was aborted by the truncation failure, so
later transactions would ignore it anyway. Now the indexes on such
a temp table are a bigger problem, but we have pretty fatal
heap-to-index consistency issues anyhow if one of the interrelated
truncates fails. We could probably minimize the danger if we did
things in the right order: truncate indexes to zero length, truncate
table to zero length, rebuild indexes as empty.
However, I'm not sure that we want to do that in the back branches,
because it would require adding write-or-drop booleans to some
higher-level functions like smgrtruncate, thus greatly increasing
the risk of breaking 3rd-party code.
regards, tom lane