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

> 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. :)

Galy Lee
lee.galy _at_
NTT Open Source Software Center

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to