Simon Riggs wrote:
> Galy, please hear that people like your idea and understand your use
> case, but just don't like all of the proposal, just the main thrust of
> it. The usual way is that
> (people that agree + amount of your exact idea remaining) = 100%
Thank you. I am glad to hear that. :) But I still can not kill my
idea yet.
Let's come to the core issue we care about: do we need the stop-on-dime
feature to stop vacuum immediately? As my previous opinion: if there
are some problems for long running vacuum, yes we *did need* to stop
vacuum immediately.
I am still not convinced that we don’t have such kind of problems. The
potential problem for running a long vacuum is that it may block some
foreground transactions, like ALTER TABLE; if it is true that long
running vacuum did block some DDLs for a long time, it is a big problem.
I think we need to stop vacuum immediately to handle such kind of
problems.
I admit that the implementation is much complex, but I can not
see any big problems to save the dead tuples out and read it in
again(like two phase commit does). Why do we need to hold the lock
and transaction? We can open the lock and abandon the transaction ID,
vacuum can take the lock and get a new ID when restarting. Why do we
need to worry about if the dead tuple is still alive, only vacuum will
sweep them, HOT can not touch the tuple until we have finished sweeping.
But it is true that in some scenarios, it is better to stop after
the cycle has finished, then the effect of vacuum can appear quickly.
So I hope the final design may combine then together.
