| 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: | E1539E0ED7043848906A8FF995BDA57901CAFFC5@m0143.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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.
Thus:
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 ...
Andreas
| 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 |