Re: Resumable vacuum proposal and design overview

Galy Lee <lee(dot)galy(at)oss(dot)ntt(dot)co(dot)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