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

Re: Resumable vacuum proposal and design overview

From: "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>
To: "Galy Lee" <lee(dot)galy(at)oss(dot)ntt(dot)co(dot)jp>,"Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"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 13:28:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> 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). Why do we need to 
> hold the lock and transaction? We can open the lock and 
> abandon the transaction ID, vacuum can take the lock and get 

> a new ID when restarting. Why do we need to worry about if 
> the dead tuple is still alive, only vacuum will sweep them, 
> HOT can not touch the tuple until we have finished sweeping.

One imho important (not necessarily mandatory) aspect of HOT is, that it
does parts of what vacuum would usually do.

	1. resume, load ctid list
	2. continue filling ctid list
	3. remove index tuples for these ctids (* problem *)

You have just removed index entries for possibly now live tuples that
have been reused by HOT.
Unless ...


In response to


pgsql-hackers by date

Next:From: Merlin MoncureDate: 2007-03-01 13:32:57
Subject: Re: [HACKERS] urgent: upgraded to 8.2, getting kernel panics
Previous:From: Zeugswetter Andreas ADI SDDate: 2007-03-01 13:24:47
Subject: Re: COMMIT NOWAIT Performance Option

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