Tom Lane wrote:
> Whether that's common enough to be worth special optimization, I'm
> not sure. Your point that the transaction may have been heavyweight
> enough that it'd hardly matter is still on-target, you just got there
> by the wrong reasoning ;-)
My point is that there is hardly any effort needed to code this (Certainly
less then what went into the mails about this until now ;-). As far as
I can see, it's adding a parameter "bool *allRelsTemp" to GetPendingDeletes,
and doing "*allRelsTemp &&= pendingDelete->isTemp" in that function.
So IMHO the question is really only about increasing the possibility of
file leakage this optimization would introduce, not about the effort needed
to implement this.
And actually, with that point of view, Simon's argument is actually in *favor*
of *allowing* asynchronous commit if only temptables are to be deleted.
Because *if* the transaction did a lot of work after creating a
(on-commit drop) temp table, then window where a crash leads to file leakage
*is* already very large. So it bit more by waiting for the wal writer
to flush the COMMIT record won't matter much.
I just wanted to write that I'll let this matter rest now, since IMHO none
of the arguments, neither pro nor contra, are really convincing, and so
keeping the status quo seems to be the most appropriate.
But just that second Alvaro's mail showed up in my inbox, saying that
temptable files are created in a special directory anyway, so cleaning
*them* up after a crash is really easy. If that is true for all
tablespaces, then this might be the convincing argument in favour of
allowing asynchronous commit if all pending deletes are temptables.
greetings, Florian Pflug