Galy Lee <lee.galy@oss.ntt.co.jp> writes:
> 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.
There's always SIGINT. The question you are avoiding is whether it's
really worth adding a lot of overhead to make vacuum able to stop
without losing some work.
> 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).
The big problem is that this creates a number of failure scenarios that
didn't exist before. Your proposal to store the dead-tuple TIDs in a
separate file scares the heck out of me: there are any number of ways
for that to get out-of-sync with the underlying relation. If you don't
see the point here, go back to re-read the documentation about PITR and
how one creates a base backup and exactly why that behavior is proof
against crashes.
regards, tom lane
