Re: Bug in VACUUM FULL ?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bug in VACUUM FULL ?
Date: 2007-03-10 00:49:41
Message-ID: 5248.1173487781@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> So txn 4's xmin is txn 3, leaving the global OldestXmin = txn 3 which lies
> between txn 1 and txn 2.

> And the tuple chain consists of two tuples. The original which has xmax
> younger than OldestXmin and so is RECENTLY_DEAD. And the updated tuple which
> has xmax older than OldestXmin and so is DEAD even though it has xmin younger
> than OldestXmin.

Right.

> Hm, I wonder if you could just notice that xmin is younger than OldestXmin.

You can see that at the newer tuple, but the problem is to propagate the
knowledge back to the older tuple(s). Or were you suggesting that we
treat the newer tuple as RECENTLY_DEAD instead of DEAD? That seems a
step backwards in space-reclamation ability. It'd be hard to implement
in any case, because one of the problem cases is where VACUUM has
already recycled the DEAD tuple before visiting the RECENTLY_DEAD tuple
that chains to it.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthew T. O'Connor 2007-03-10 00:49:43 Re: autovacuum next steps, take 3
Previous Message Gregory Stark 2007-03-10 00:43:15 Re: Bug in VACUUM FULL ?