Re: Resumable vacuum proposal and design overview

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Galy Lee <lee(dot)galy(at)oss(dot)ntt(dot)co(dot)jp>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Zeugswetter Andreas ADI SD <ZeugswetterA(at)spardat(dot)at>, "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Resumable vacuum proposal and design overview
Date: 2007-03-01 06:17:03
Message-ID: 16072.1172729823@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2007-03-01 06:36:12 Possible BUG in -head with stats
Previous Message Denis Lussier 2007-03-01 06:08:46 Re: Packed short varlenas, what next?