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-24 00:09:03 |
Message-ID: | 3C26721F.B8647815@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> >> 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* ?
>
> [ reads it again ] Oh, you're right.
>
> Still, if WAL isn't taking care to maintain t_ctid then we have a
> problem.
I don't think it's preferable either. However there's
no problem unless there's an application which handle
the tuples containing the t_ctid link. I know few
applications(vacuum, create index ??) which handles
the tuples already updated to new ones and committed
before the transaction started.
Note that redo is executed alone. Shutdown recovery
is called after killing all backends if necessary.
Of cource there are no other backends running when
startup recovery is called.
regards,
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-12-24 00:44:44 | Re: Possible bug in vacuum redo |
Previous Message | Hannu Krosing | 2001-12-23 22:24:22 | Re: Possible bug in vacuum redo |