Re: Possible bug in vacuum redo
От | Hiroshi Inoue |
---|---|
Тема | Re: Possible bug in vacuum redo |
Дата | |
Msg-id | EKEJJICOHDIEMGPNIFIJGEIMGEAA.Inoue@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: Possible bug in vacuum redo (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Possible bug in vacuum redo
|
Список | pgsql-hackers |
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > "Hiroshi Inoue" <Inoue@tpf.co.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
В списке pgsql-hackers по дате отправления: