Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group