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
Views: Raw Message | Whole Thread | Download 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


Browse pgsql-hackers by date

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