Skip site navigation (1) Skip section navigation (2)

Re: Possible bug in vacuum redo

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Possible bug in vacuum redo
Date: 2001-12-22 23:35:58
Message-ID: EKEJJICOHDIEMGPNIFIJGEIMGEAA.Inoue@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> 
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> > AFAIR t_ctid isn't logged in WAL.
> 
> After looking at the heap_update code I think you are right.  Doesn't
> that render the field completely useless/unreliable?

Redo runs with no concurrent backends. New backends invoked
after a redo operation don't need(see)  the existent t_ctid values.
PostgreSQL before MVCC didn't need the t_ctid.

> 
> In the simple heap_update case I think that heap_xlog_update could
> easily set the old tuple's t_ctid field correctly.  Not sure how
> it works when VACUUM is moving tuple chains around, however.
> 
> Another thing I am currently looking at is that I do not believe VACUUM
> handles tuple chain moves correctly.  It only enters the chain-moving
> logic if it finds a tuple that is in the *middle* of an update chain,
> ie, both the prior and next tuples still exist. 
       ^^^^^
Isn't it *either* not *both* ?
Anyway I agree with you at the point that the tuple chain-moving
is too complex. It's one of the main reason why I prefer the new
VACUUM.

regards,
Hiroshi Inoue

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-12-23 00:15:52
Subject: Re: HISTORY file
Previous:From: Peter EisentrautDate: 2001-12-22 21:41:51
Subject: HISTORY file

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group