RE: Is VACUUM still crash-safe?

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: Is VACUUM still crash-safe?
Date: 2000-12-11 17:19:34
Message-ID: 8F4C99C66D04D4118F580090272A7A234D31ED@sectorbase1.sectorbase.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > When VACUUM for a table starts, the transaction is not
> > committed yet of cource. After *commit* VACUUM has handled
> > heap/index tuples very carefully to be crash-safe before
> > 7.1. Currently another vacuum could be invoked in the
> > already committed transaction. There has been no such
> > situation before 7.1. Yes,VACUUM isn't crash-safe now.
>
> Vadim, do you agree with this argument? If so, I think it's
> something we need to fix. I don't see what Hiroshi is worried
> about, myself, but if there really is an issue here...

If we move tuples in already committed state, a page with new
tuple position goes to disk and backend crashes before page with
old tuple position updated then we'll have two version of tuple
after restart (new tuple with HEAP_MOVED_IN is valid and there is
no HEAP_MOVED_OFF in old tuple version).
I don't know how bad is it for TOAST tables though.

Vadim
P.S. I had no Inet access on weekends - my home phone line was broken...

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mikheev, Vadim 2000-12-11 17:20:41 RE: suggest remove of elog in xlog.c
Previous Message Peter Eisentraut 2000-12-11 17:08:33 Re: v7.1 beta 1 ...packaged, finally ...