Re: [HACKERS] Concurrent VACUUM: first results

From: Vadim Mikheev <vadim(at)krs(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Concurrent VACUUM: first results
Date: 1999-11-26 06:58:31
Message-ID: 383E2F97.2ECD92F6@krs.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>
> While I'm asking silly questions: why does VACUUM relabel tuples
> with its own xact ID anyway? I suppose that's intended to improve
> robustness in case of a crash --- but if there's a crash partway
> through VACUUM, it seems like data corruption is inevitable. How
> can you pack tuples into the minimum number of pages without creating
> duplicate or missing tuples, if you are unlucky enough to crash before
> deleting the tuples from their original pages?

VACUUM:
1. has to preserve t_xmin/t_xmax in moved tuples
(or MVCC will be broken) and so stores xid in t_cmin.
2. turns HEAP_XMIN_COMMITTED off in both tuple versions
(in old and new places).
3. sets HEAP_MOVED_IN in tuples in new places and
HEAP_MOVED_OFF in tuples in old places.

Seeing HEAP_MOVED_IN/HEAP_MOVED_OFF (this is tested for
tuples with HEAP_XMIN_COMMITTED off only, just to don't
test in all cases) tqual.c funcs will check is tuple->t_cmin
committed or not - ie was VACUUM succeded in moving or not.
And so, single vacuum xid commit ensures that there will be
neither duplicates nor lost tuples.

Sorry, I should to describe this half year ago, but...

Vadim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Adriaan Joubert 1999-11-26 07:12:09 Re: [HACKERS] Re: [GENERAL] Update of bitmask type
Previous Message Chairudin Sentosa Harjo 1999-11-26 06:55:13 Re: pg_ctl