| From: | Galy Lee <lee(dot)galy(at)oss(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | 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-02-28 10:02:45 |
| Message-ID: | 45E55345.20505@oss.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Simon Riggs wrote:
> You haven't explained how saving the dead-tuple-list could be done
> in a safe mannner and it seems risky to me.
The files are placed in a new directory $PGDATA/pg_vacuum
with the name: spcNode.dbNode.relNode for each relations
which have been interrupted during vacuum.
It has the format likes:
1. VacStateFileHeader
2. VacStateData
3. Dead Tuple list
4. CRC32
The files are removed
- when original physical heap files are removed,
- when vacuum full have been issued,
- or after the content has been read in memory.
- etc.
Is there any potential big risk there? Correct me if I am
wrong.
> Deferring completion of VACUUM means deferring refreshing the FSM.
I borrow the code from DSM patch to merge free space info
into FSM when vacuum stops.
> Are you saying you know for certain this lock is held for a long time,
> or are you just saying you think it is? If you have some evidence for
> long truncation times then that would be a separate issue of concern,
> since that might starve out normal users. Please say more?
Sorry. I *thought* it is. The benchmark has not shown such
kind of problem anyway. Thanks for the clarification for me. :)
Regards,
--
Galy Lee
lee.galy _at_ oss.ntt.co.jp
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zeugswetter Andreas ADI SD | 2007-02-28 10:19:44 | Re: Resumable vacuum proposal and design overview |
| Previous Message | Heikki Linnakangas | 2007-02-28 09:51:46 | Re: Dead Space Map version 2 |