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
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Joshua D. Drake||Date: 2007-03-01 06:36:12|
|Subject: Possible BUG in -head with stats|
|Previous:||From: Denis Lussier||Date: 2007-03-01 06:08:46|
|Subject: Re: Packed short varlenas, what next?|