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: "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 (view raw or flat)
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

In response to

pgsql-hackers by date

Next:From: Jonathan ScherDate: 2007-03-01 13:55:35
Subject: CLUSTER, using SHARE UPDATE EXCLUSIVE lock?
Previous:From: Heikki LinnakangasDate: 2007-03-01 13:51:43
Subject: Re: COMMIT NOWAIT Performance Option

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