| From: | "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>, "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:52:16 |
| Message-ID: | E1539E0ED7043848906A8FF995BDA57901CAFFD9@m0143.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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.
Sorry my error, this is no problem, since HOT can only reuse a slot that
has no direct index entries (part of an old HOT chain).
So with HOT it is only important, that the 1st heap scan ignores
(does not add to the list) HOT chained tuples.
So, I still don't feel comfortable with the idea of breaking the
visibility rules (using a ctid that is days old and globalxmin not
knowing), even if I do not currently see a direct problem that cannot be
worked around (like removing all lists upon startup recovery).
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jonathan Scher | 2007-03-01 13:55:35 | CLUSTER, using SHARE UPDATE EXCLUSIVE lock? |
| Previous Message | Heikki Linnakangas | 2007-03-01 13:51:43 | Re: COMMIT NOWAIT Performance Option |